From 9cea1118e3aaa12943da50c9da51c54d8d750585 Mon Sep 17 00:00:00 2001 From: Thijs van Emmerik Date: Tue, 8 Sep 2026 13:30:43 +0000 Subject: [PATCH 1/4] docs: add contributor rewards management and revise rack and power guidance --- docs/contribute-overview.md | 10 +- docs/contribute-provisioning.md | 59 ++++++- docs/contribute-rewards.md | 292 ++++++++++++++++++++++++++++++++ docs/contribute.md | 33 +++- docs/glossary.md | 3 + mkdocs.yml | 1 + 6 files changed, 384 insertions(+), 14 deletions(-) create mode 100644 docs/contribute-rewards.md diff --git a/docs/contribute-overview.md b/docs/contribute-overview.md index 9ba863c..608e073 100644 --- a/docs/contribute-overview.md +++ b/docs/contribute-overview.md @@ -21,16 +21,20 @@ Use this checklist to track your progress. **All items must be complete before y ### Phase 1: Prerequisites - [ ] DoubleZero CLI installed on a management server - [ ] Hardware procured and meets [requirements](contribute.md#hardware-requirements) -- [ ] Data center rack space and power available (4U, 4KW recommended) +- [ ] Data center rack space and power available (see [Rack & Power](contribute.md#rack-power-requirements)) - [ ] DZD physically installed with management connectivity - [ ] Public IPv4 block allocated for DZ protocol (**see [DZ Prefix Rules](#dz-prefix-rules)**) ### Phase 2: Account Setup - [ ] Service keypair generated (`doublezero keygen`) - [ ] Metrics publisher keypair generated -- [ ] Service key submitted to DZF for authorization +- [ ] Rewards manager wallet created and funded with ~0.01 SOL +- [ ] Service key, rewards manager key and GitHub username submitted to DZF (public keys only) - [ ] Contributor account created onchain (verify with `doublezero contributor list`) +- [ ] Rewards manager key registered onchain by DZF - [ ] Access granted to [malbeclabs/contributors](https://github.com/malbeclabs/contributors) repository +- [ ] Recipient wallets and percentages configured (**see [Rewards Management](contribute-rewards.md)**) +- [ ] Each recipient wallet has a 2Z token account ### Phase 3: Device Provisioning - [ ] Base device configuration applied (from contributors repo) @@ -127,6 +131,7 @@ New to DoubleZero? Here are the essential terms (see [full Glossary](glossary.md | **Telemetry Agent** | Collects TWAMP latency/loss metrics, submits to onchain ledger | | **Service Key** | Your contributor identity key for CLI operations | | **Metrics Publisher Key** | Key for signing telemetry submissions onchain | +| **Rewards Manager Key** | Key that controls which wallets receive your rewards | --- @@ -138,6 +143,7 @@ New to DoubleZero? Here are the essential terms (see [full Glossary](glossary.md |-------|-------------| | [Requirements & Architecture](contribute.md) | Hardware specs, network architecture, bandwidth options | | [Device Provisioning](contribute-provisioning.md) | Step-by-step: keys → repo access → device → links → agents | +| [Rewards Management](contribute-rewards.md) | Setting the wallets that receive your 2Z rewards | | [Operations](contribute-operations.md) | Agent upgrades, link management, monitoring | | [Geoprobe Deployment](contribute-geolocation.md) | Deploying and configuring geoProbe agents for geolocation | | [Glossary](glossary.md) | All DoubleZero terminology defined | diff --git a/docs/contribute-provisioning.md b/docs/contribute-provisioning.md index 8ae6669..1092058 100644 --- a/docs/contribute-provisioning.md +++ b/docs/contribute-provisioning.md @@ -88,8 +88,8 @@ Before you can provision a device, you need the physical hardware set up and som | Requirement | Why It's Needed | |-------------|-----------------| | **DZD Hardware** | Arista 7280CR3A switch (see [hardware specs](contribute.md#hardware-requirements)) | -| **Rack Space** | 4U with proper airflow | -| **Power** | Redundant feeds, ~4KW recommended | +| **Rack Space** | 1U per DZD, with proper airflow. See [Rack & Power](contribute.md#rack-power-requirements) | +| **Power** | Two independent feeds, each able to carry the whole load on its own. See [Rack & Power](contribute.md#rack-power-requirements) | | **Management Access** | SSH/console access to configure the switch | | **Internet Connectivity** | For metrics publishing and to fetch configuration from the controller | | **Public IPv4 Block** | Minimum /29 for the DZ prefix pool (see below) | @@ -163,7 +163,9 @@ flowchart LR ## Phase 2: Account Setup -In this phase, you create the cryptographic keys that identify you and your devices on the network. +In this phase, you create the cryptographic keys that identify you and your devices on the network, and you say where your rewards should be paid. + +Three keys come out of this phase: a service key, a metrics publisher key, and a rewards manager key. Submit the public keys for all three to DZF together in [Step 2.4](#step-24-submit-keys-to-dzf). [Rewards Management](contribute-rewards.md) covers the rewards side in full. ### Where to Run the CLI @@ -199,20 +201,26 @@ Think of keys like secure login credentials: - **Service Key**: Your contributor identity - used to run CLI commands - **Metrics Publisher Key**: Your device's identity for submitting telemetry data +- **Rewards Manager Key**: Controls which wallets receive your rewards - see [Rewards Management](contribute-rewards.md) -Both are cryptographic keypairs (a public key you share, a private key you keep secret). +All three are cryptographic keypairs (a public key you share, a private key you keep secret). ```mermaid flowchart LR subgraph "Your Keys" SK[Service Key
~/.config/solana/id.json] MK[Metrics Publisher Key
~/.config/doublezero/metrics-publisher.json] + RK[Rewards Manager Key
keep offline] end SK -->|Used for| CLI[CLI Commands
doublezero device create
doublezero link create] MK -->|Used for| TEL[Telemetry Agent
Submits metrics onchain] + RK -->|Used for| REW[Rewards Portal
Sets recipient wallets] ``` +!!! note "Keep the rewards manager key separate" + The service key and metrics publisher key live on your management server and switch. The rewards manager key controls where your money goes, so keep it off those machines. It is only needed when you change your recipient wallets. + ### Step 2.1: Generate Your Service Key This is your main identity for interacting with DoubleZero. @@ -231,19 +239,34 @@ This key is used by the Telemetry Agent to sign metric submissions. doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Step 2.3: Submit Keys to DZF +### Step 2.3: Create Your Rewards Manager Wallet + +This is the third key. It controls which wallets receive your rewards, and it never holds them. + +Create a Solana wallet you control and can sign with, then fund it with about 0.01 SOL to cover transaction fees. A hardware wallet is a good choice. Do not reuse your service key. + +You only need the wallet at this point. You will set the wallets that actually receive your rewards in [Step 2.7](#step-27-set-your-reward-recipients), after DZF has registered this key. + +### Step 2.4: Submit Keys to DZF Contact the DoubleZero Foundation or Malbec Labs and provide: 1. Your **service key public key** -2. Your **GitHub username** (for repo access) +2. Your **rewards manager public key** (from Step 2.3) +3. Your **GitHub username** (for repo access) + +Send all three together. DZF registers the service key and the rewards manager key in separate onchain transactions, so sending them at the same time saves a round trip. + +!!! danger "Public keys only" + Never send a private key or a keypair file to anyone, including DZF. DZF only ever needs your public keys. They will: - Create your **contributor account** onchain +- Register your **rewards manager key** against your service key - Grant access to the private **contributors repository** -### Step 2.4: Verify Your Account +### Step 2.5: Verify Your Account Once confirmed, verify your contributor account exists: @@ -253,7 +276,16 @@ doublezero contributor list You should see your contributor code in the list. -### Step 2.5: Access the Contributors Repository +Check that your rewards manager key was registered too: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` + +The `manager` column should show your rewards manager public key. If it is empty, ask DZF to complete that step. + +### Step 2.6: Access the Contributors Repository The [malbeclabs/contributors](https://github.com/malbeclabs/contributors) repository contains: @@ -264,6 +296,17 @@ The [malbeclabs/contributors](https://github.com/malbeclabs/contributors) reposi Follow the instructions there for device-specific configuration. +### Step 2.7: Set Your Reward Recipients + +Now say which wallets receive your rewards, and in what proportions. Do this before your device starts carrying traffic. Rewards build up from the moment your links are live, but the protocol cannot pay them out until you have nominated recipient wallets. + +Sign in to [doublezero.xyz/rewards](https://doublezero.xyz/rewards) with your rewards manager wallet, select your service key, then enter each recipient wallet and its percentage. The percentages must add up to 100. + +!!! warning "Each recipient needs a 2Z token account" + The protocol sends 2Z with a plain token transfer and does not create the token account for you. A recipient wallet with no 2Z token account causes that epoch's payout to fail. + +See [Rewards Management](contribute-rewards.md) for the full walkthrough, including the CLI alternative, how to check the token account, and how to verify the result. + --- ## Phase 3: Device Provisioning diff --git a/docs/contribute-rewards.md b/docs/contribute-rewards.md new file mode 100644 index 0000000..2039c55 --- /dev/null +++ b/docs/contribute-rewards.md @@ -0,0 +1,292 @@ +--- +description: Set up rewards management so the 2Z rewards earned by your DoubleZero contribution are paid to wallets you control. +--- + +# Rewards Management + +You earn rewards in [2Z](glossary.md#2z-token) for the bandwidth and devices you contribute. The protocol pays those rewards out on its own, straight to wallets you nominate. Until you nominate them, nothing can be paid out. + +!!! warning "Do this during account setup" + Set up rewards management in [Phase 2: Account Setup](contribute-provisioning.md#phase-2-account-setup), before your device carries traffic. + + Your rewards still accrue if you leave this until later. The protocol does not burn them and they do not expire. What you lose is the automatic payout: the routine payout process works through recent epochs, so any epoch that passes while you have no recipients set has to be paid out by hand afterwards. See [If You Set This Up Late](#if-you-set-this-up-late). + +--- + +## How It Works + +Three keys are involved. Each does a different job, and it is safer to keep them separate. + +| Key | What it does | Receives rewards? | +|-----|--------------|-------------------| +| **Service key** | Identifies you as a contributor and signs your CLI commands. Also names your rewards account onchain. | No | +| **Rewards manager key** | Signs changes to the list of wallets that receive rewards. | No | +| **Recipient wallet(s)** | Holds the 2Z the protocol sends you. Up to 8 wallets. | Yes | + +The DoubleZero Foundation registers your rewards manager key against your service key. Only DZF can do that. After that, only your rewards manager key can change the recipient list, and DZF cannot redirect your rewards. + +```mermaid +flowchart LR + DZF["DZF"] -->|"Registers your
rewards manager key"| ACC["Your rewards account
onchain"] + RM["Rewards manager key
(you hold, keep offline)"] -->|"Sets recipients
and percentages"| ACC + ACC --> R1["Recipient wallet 1"] + ACC --> R2["Recipient wallet 2"] + PROTO["Protocol pays out
each DZ epoch"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## What You Need First + +- A contributor account onchain. Check with `doublezero contributor list`. +- A Solana wallet to act as your rewards manager, holding about 0.01 SOL to pay transaction fees. +- One or more wallets to receive the 2Z. +- The `doublezero-solana` CLI, if you want to use the command line instead of the portal. Install it with `sudo apt update && sudo apt install doublezero-solana`. + +!!! tip "Use a hardware wallet for the rewards manager key" + The rewards manager key controls where your money goes. Keep it on a hardware wallet or otherwise offline. It never needs to sit on a server, and it never holds your rewards. + +--- + +## Step 1: Create Your Rewards Manager Wallet + +Create a Solana wallet you control and can sign with. This can be a hardware wallet, a browser wallet, or a keypair file. + +Fund it with a small amount of SOL, around 0.01 SOL. This only pays network fees when you change your recipient list. + +Do not reuse your service key for this. If the service key sits on a management server, anyone who reaches that server could redirect your rewards. + +--- + +## Step 2: Send the Public Key to DZF + +Give DZF the **public key** of your rewards manager wallet. Never share the private key. + +DZF registers it against your service key onchain and confirms when it is done. You cannot do this step yourself. + +!!! tip "Send it with your service key" + If you are working through the [Device Provisioning Guide](contribute-provisioning.md), send this public key at the same time as your service key and GitHub username, in [Step 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). DZF registers the two keys in separate transactions, so sending them together saves a round trip. + +You can check it landed: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +The `manager` column shows your rewards manager key. If it is empty, DZF has not registered it yet. + +--- + +## Step 3: Set Your Recipient Wallets + +Now say where the rewards should go. You can use the web portal or the CLI. Both write the same thing onchain. + +Rules that apply either way: + +- At most 8 recipient wallets. +- Percentages must be whole numbers and must add up to exactly 100. +- A recipient cannot have a 0% share. Remove it instead. + +!!! info "If your agreement with DZF includes a revenue share" + Some contributors have an agreement that splits rewards with the foundation, for example where DZF supplied the hardware. If that applies to you, DZF gives you the address and the percentage to enter here. Ask DZF if you are unsure. + +=== "Web portal" + + 1. Go to [doublezero.xyz/rewards](https://doublezero.xyz/rewards). The old address, `rewards.doublezero.xyz`, redirects here. + 2. Connect your rewards manager wallet with the wallet button in the top right. + 3. Select your service key from the list on the next page. + 4. Enter each recipient wallet address and its percentage. The total must be 100%. + 5. Click **Submit** and approve the transaction in your wallet. + +=== "CLI" + + Run this with your rewards manager keypair as `-k`. Repeat `--recipient` for each wallet. + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | Flag | Description | + |------|-------------| + | `--service-key` | Your contributor service key. This names the rewards account onchain. | + | `--recipient` | A recipient in the form `PUBKEY:PERCENT`. Whole numbers, 1 to 100, adding up to 100. Maximum 8. | + | `-k` | Your rewards manager keypair. The transaction fails if this is not the registered rewards manager. | + | `-u` | `mainnet-beta`. | + + Add `--dry-run` first if you want to simulate the transaction without sending it. + +--- + +## Step 4: Check Each Recipient Can Hold 2Z + +The protocol sends 2Z with a plain token transfer. It does **not** create the token account for you. If a recipient wallet has no 2Z token account, the payout for that epoch fails. + +The 2Z mint on mainnet is: + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +List the token accounts a wallet already has: + +```bash +spl-token accounts --owner -u m +``` + +If `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` is missing from that list, create the account once: + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +Any funded wallet can pay for this. It costs a small amount of SOL and only has to be done once per recipient wallet. + +!!! note "Wallets that already hold 2Z are fine" + If the wallet has ever received 2Z, the token account exists and you can skip this step. + +--- + +## Step 5: Verify + +Check what is now recorded onchain: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +Example output: + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +The `ata` column is the 2Z token account each recipient will be paid into. Check the `proportion` column adds up to 100%. + +--- + +## When Rewards Arrive + +- Rewards are worked out per **DZ epoch**, which is the epoch of the DoubleZero Ledger. A DZ epoch runs roughly two days. +- Payout for an epoch happens around 10 DZ epochs after that epoch ends, so about 20 days later. This lag covers the accounting for the epoch. +- Payouts are automatic. You do not claim them, and you do not need to run anything. +- Once your recipients are set, payouts start arriving within a couple of days as the next epochs are worked through. Epochs that passed before you set your recipients are a separate matter, see [If You Set This Up Late](#if-you-set-this-up-late). +- A DZ epoch and a Solana epoch are not the same length. That difference adds up over time, so now and then a DZ epoch shows zero rewards. This is expected. + +--- + +## Where to See Your Rewards + +**Aggregate view.** The [Economic Hub](https://doublezero.xyz/economic-hub) shows contributor rewards at a network level. + +**Per epoch.** Ask the protocol what a given DZ epoch paid out: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +The output lists every contributor with its share, its reward in 2Z, and whether the payout has been made. Find your contributor code in the `contributor` column. + +To see which DZ epoch the network is on now, leave `-e` off: + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "Recent epochs are not final yet" + Asking for an epoch whose rewards have not been worked out yet returns `Rewards calculation is not finalized yet`. Try an older epoch. + +--- + +## If You Set This Up Late + +Rewards are worked out for every epoch you contributed, whether or not you had recipients configured at the time. Those rewards are not burned and they do not expire. They sit in that epoch's distribution account until someone submits the payout. + +The catch is that nothing submits them for you after the fact. The routine payout process works through recent epochs, so an epoch that passed while your recipient list was empty stays unpaid until it is submitted by hand. + +To find which epochs are affected, look for rows with your contributor code where `distributed` is `no` and the reward is above zero: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +Submitting the payout is permissionless, so once your recipients are configured, any funded wallet can do it, including your own: + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +Add `--dry-run` first to simulate it without sending anything. The command works through every contributor in that epoch and skips the ones already paid, so it is safe to run. + +If you would rather not do this yourself, ask DZF to submit the epochs for you. + +--- + +## Changing Recipients Later + +Repeat [Step 3](#step-3-set-your-recipient-wallets) at any time. The new list replaces the old one in full, so include every recipient you still want, not just the ones you are adding. Percentages must add up to 100 again. + +Remember [Step 4](#step-4-check-each-recipient-can-hold-2z) for any wallet you add. + +--- + +## Locking the Rewards Manager Key + +By default DZF can change your rewards manager key, which is useful if you lose access to it. If you would rather rule that out, you can block it: + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "Do not lock a key you might lose" + Once management is blocked, nobody can replace your rewards manager key, including DZF. If you then lose that key you can no longer change where your rewards go. Only block it if the key is backed up and safe. + +To allow it again, run the same command with `--allow-protocol-management`. + +--- + +## Troubleshooting + +**The `manager` column is empty.** +DZF has not registered your rewards manager key yet. Send them the public key and ask them to confirm. + +**`Invalid rewards manager`.** +The keypair you signed with is not the registered rewards manager. Check you passed the right file to `-k`, or the right wallet in the portal. + +**`Invalid recipients`.** +Your percentages do not add up to exactly 100, you listed more than 8 recipients, or one of them has a 0% share. + +**Rewards show as earned but nothing arrives.** +Two common causes. Either no recipients are configured, so there is nowhere to send them, or a recipient wallet has no 2Z token account. Work through [Step 4](#step-4-check-each-recipient-can-hold-2z) and [Step 5](#step-5-verify). Once that is fixed, future epochs pay out on their own. Epochs that already passed need [a manual payout](#if-you-set-this-up-late). + +**Your rewards for a recent epoch are 0.** +Rewards lag by about 10 DZ epochs. Check an epoch that is at least that old. Occasional zero epochs are also normal, see [When Rewards Arrive](#when-rewards-arrive). + +--- + +## Next Steps + +Back to the [Onboarding Checklist](contribute-overview.md#onboarding-checklist), or on to [Operations](contribute-operations.md). diff --git a/docs/contribute.md b/docs/contribute.md index f1b35b1..d98b2ba 100644 --- a/docs/contribute.md +++ b/docs/contribute.md @@ -222,10 +222,35 @@ Please ensure that the full /29 pool is available for the DZ protocol. Any requ #### Rack & Power Requirements -| Requirement | Specification | -|-------------|--------------| -| Rack Space | 4U | -| Power | 4KW (recommended) | +The figures below are **per DZD**, so per data center. A 100G or 10G bandwidth contribution puts one DZD at each end of the link, so plan this twice. + +##### Rack space + +| Item | Rack units | Needed | +|------|-----------|--------| +| DZD switch (Arista 7280CR3A-32S or 7130LBR) | 1U | Now | +| Edge filtering appliance | 1U | Later, on edge and hybrid devices only | + +**Reserve 2U per DZD.** One unit is in use today. Keep the second free so the edge filtering appliance can go in next to the switch without a rack move. Leave room for airflow and cable management as your facility requires. + +##### Power + +| Item | Typical draw | +|------|-------------| +| Arista 7280CR3A-32S | ~300 W | +| Optics, per 100G QSFP | ~5 W | + +**Order 2 kW per DZD, split across two independent feeds.** Size each feed to carry the whole load on its own. The switch runs redundant power supplies, and after a feed failure one of them may be all you have left. + +2 kW is comfortable rather than tight. A switch-only DZD, which is what almost every deployment runs today, draws well under 500 W with all its optics lit. The rest of the 2 kW is set aside for the edge filtering appliance, which holds the FPGAs and goes in later. + +!!! warning "Do not over-order power" + You pay for the power you reserve, whether you draw it or not. A DZD is a single rack unit of switching, not a compute chassis, so it draws far less than its rack position could supply. Reserving more than 2 kW per DZD means paying for capacity that sits idle. + +!!! note "Check your own hardware before you order" + These are guideline figures from our own deployments. Your real draw depends on your power supply configuration, how many ports you light up, and which optics you choose. Confirm against the power supply ratings in the vendor datasheet for the exact hardware you buy. + + Do not trim the order to the bare minimum either. The power has to be available in the rack, and adding a feed later usually means a new order with the facility, which can take weeks. --- diff --git a/docs/glossary.md b/docs/glossary.md index 7c23ddf..3dac5d8 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -162,6 +162,9 @@ A cryptographic keypair used to authenticate CLI operations. This is your contri ### Metrics Publisher Key A cryptographic keypair used by the [Telemetry Agent](#telemetry-agent) to sign metric submissions to the blockchain. Separate from the service key for security isolation. Stored at `~/.config/doublezero/metrics-publisher.json`. +### Rewards Manager Key +A cryptographic keypair that controls where a contributor's rewards are paid. It signs changes to the list of recipient wallets but never holds rewards itself. Registered against the contributor's [Service Key](#service-key) by [DZF](#dzf-doublezero-foundation). See [Rewards Management](contribute-rewards.md). + --- ## Hardware & Software diff --git a/mkdocs.yml b/mkdocs.yml index 1f5b4da..6b61193 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -101,6 +101,7 @@ nav: - Overview: contribute-overview.md - Requirements & Architecture: contribute.md - Device Provisioning: contribute-provisioning.md + - Rewards Management: contribute-rewards.md - Operations: contribute-operations.md - OPS Management: contribute-ops-management.md - Geolocation: contribute-geolocation.md From e21966c6ed48ed2d62a24894cc2c3cba669c3ee1 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 8 Sep 2026 14:25:33 +0000 Subject: [PATCH 2/4] chore: auto-translate docs --- docs/contribute-overview.es.md | 145 ++-- docs/contribute-overview.fr.md | 181 ++--- docs/contribute-overview.it.md | 145 ++-- docs/contribute-overview.ja.md | 219 +++--- docs/contribute-overview.ko.md | 181 ++--- docs/contribute-overview.pt.md | 149 ++-- docs/contribute-overview.zh.md | 223 +++--- docs/contribute-provisioning.es.md | 949 +++++++------------------ docs/contribute-provisioning.fr.md | 999 ++++++++------------------ docs/contribute-provisioning.it.md | 879 +++++++---------------- docs/contribute-provisioning.ja.md | 1043 ++++++++-------------------- docs/contribute-provisioning.ko.md | 998 ++++++-------------------- docs/contribute-provisioning.pt.md | 880 +++++++---------------- docs/contribute-provisioning.zh.md | 969 +++++++------------------- docs/contribute-rewards.es.md | 292 ++++++++ docs/contribute-rewards.fr.md | 292 ++++++++ docs/contribute-rewards.it.md | 292 ++++++++ docs/contribute-rewards.ja.md | 292 ++++++++ docs/contribute-rewards.ko.md | 292 ++++++++ docs/contribute-rewards.pt.md | 292 ++++++++ docs/contribute-rewards.zh.md | 292 ++++++++ docs/contribute.es.md | 179 +++-- docs/contribute.fr.md | 231 +++--- docs/contribute.it.md | 226 +++--- docs/contribute.ja.md | 198 +++--- docs/contribute.ko.md | 196 +++--- docs/contribute.pt.md | 151 ++-- docs/contribute.zh.md | 219 +++--- docs/glossary.es.md | 61 +- docs/glossary.fr.md | 91 +-- docs/glossary.it.md | 73 +- docs/glossary.ja.md | 121 ++-- docs/glossary.ko.md | 75 +- docs/glossary.pt.md | 83 +-- docs/glossary.zh.md | 111 +-- 35 files changed, 5605 insertions(+), 6414 deletions(-) create mode 100644 docs/contribute-rewards.es.md create mode 100644 docs/contribute-rewards.fr.md create mode 100644 docs/contribute-rewards.it.md create mode 100644 docs/contribute-rewards.ja.md create mode 100644 docs/contribute-rewards.ko.md create mode 100644 docs/contribute-rewards.pt.md create mode 100644 docs/contribute-rewards.zh.md diff --git a/docs/contribute-overview.es.md b/docs/contribute-overview.es.md index 902b0fe..a9bd710 100644 --- a/docs/contribute-overview.es.md +++ b/docs/contribute-overview.es.md @@ -1,88 +1,94 @@ -# Documentación para Contribuidores -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Descripción general y lista de verificación de incorporación para convertirse en contribuidor de la red DoubleZero. +--- +# Documentación para Contribuidores !!! info "Terminología" ¿Nuevo en DoubleZero? Consulte el [Glosario](glossary.md) para definiciones de términos clave como [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) y [CYOA](glossary.md#cyoa-choose-your-own-adventure). -Bienvenido a la documentación para contribuidores de DoubleZero. Esta sección cubre todo lo que necesita para convertirse en un contribuidor de red. +Bienvenido a la documentación para contribuidores de DoubleZero. Esta sección cubre todo lo que necesita para convertirse en un contribuidor de la red. -!!! tip "¿Interesado en convertirse en contribuidor de red?" +!!! tip "¿Interesado en convertirse en contribuidor de la red?" Revise la página de [Requisitos y Arquitectura](contribute.md) para comprender el hardware, el ancho de banda y la conectividad necesarios para contribuir a la red DoubleZero. --- ## Lista de Verificación de Incorporación -Use esta lista de verificación para hacer seguimiento de su progreso. **Todos los elementos deben estar completados antes de que su contribución sea técnicamente operativa.** +Use esta lista de verificación para seguir su progreso. **Todos los elementos deben completarse antes de que su contribución esté técnicamente operativa.** -### Fase 1: Requisitos Previos -- [ ] CLI DoubleZero instalada en un servidor de gestión -- [ ] Hardware adquirido y cumple los [requisitos](contribute.md#hardware-requirements) -- [ ] Espacio en rack y energía del centro de datos disponibles (4U, 4KW recomendado) +### Fase 1: Prerrequisitos +- [ ] CLI de DoubleZero instalado en un servidor de gestión +- [ ] Hardware adquirido y cumple con los [requisitos](contribute.md#hardware-requirements) +- [ ] Espacio en rack y alimentación eléctrica disponibles en el centro de datos (consulte [Rack y Alimentación](contribute.md#rack-power-requirements)) - [ ] DZD instalado físicamente con conectividad de gestión -- [ ] Bloque IPv4 público asignado para el protocolo DZ (**consulte las [Reglas de Prefijo DZ](#dz-prefix-rules)**) +- [ ] Bloque de IPv4 público asignado para el protocolo DZ (**consulte [Reglas de Prefijos DZ](#reglas-de-prefijos-dz)**) ### Fase 2: Configuración de Cuenta - [ ] Par de claves de servicio generado (`doublezero keygen`) -- [ ] Par de claves de editor de métricas generado -- [ ] Clave de servicio enviada a DZF para autorización +- [ ] Par de claves del publicador de métricas generado +- [ ] Billetera del gestor de recompensas creada y financiada con ~0.01 SOL +- [ ] Clave de servicio, clave del gestor de recompensas y nombre de usuario de GitHub enviados a DZF (solo claves públicas) - [ ] Cuenta de contribuidor creada onchain (verificar con `doublezero contributor list`) +- [ ] Clave del gestor de recompensas registrada onchain por DZF - [ ] Acceso otorgado al repositorio [malbeclabs/contributors](https://github.com/malbeclabs/contributors) +- [ ] Billeteras receptoras y porcentajes configurados (**consulte [Gestión de Recompensas](contribute-rewards.md)**) +- [ ] Cada billetera receptora tiene una cuenta de token 2Z -### Fase 3: Aprovisionamiento de Dispositivos +### Fase 3: Aprovisionamiento del Dispositivo - [ ] Configuración base del dispositivo aplicada (desde el repositorio de contribuidores) - [ ] Dispositivo creado onchain (`doublezero device create`) - [ ] Interfaces del dispositivo registradas - [ ] Interfaces loopback creadas (Loopback255 vpnv4, Loopback256 ipv4) -- [ ] Interfaces CYOA/DIA configuradas (si es dispositivo de borde/híbrido) +- [ ] Interfaces CYOA/DIA configuradas (si es dispositivo edge/híbrido) -### Fase 4: Establecimiento de Enlace e Instalación de Agentes +### Fase 4: Establecimiento de Enlaces e Instalación de Agentes - [ ] Enlaces WAN creados (si aplica) - [ ] Enlace DZX creado (estado: `requested`) - [ ] Enlace DZX aceptado por el contribuidor par -- [ ] Agente de Configuración instalado y en ejecución -- [ ] Agente de Configuración recibiendo configuración del controlador -- [ ] Agente de Telemetría instalado y en ejecución -- [ ] Editor de métricas registrado onchain -- [ ] Presentaciones de telemetría visibles en el ledger +- [ ] Config Agent instalado y en ejecución +- [ ] Config Agent recibiendo configuración del controlador +- [ ] Telemetry Agent instalado y en ejecución +- [ ] Publicador de métricas registrado onchain +- [ ] Envíos de telemetría visibles en el ledger -### Fase 5: Rodaje del Enlace -- [ ] Todos los enlaces drenados durante un período de rodaje de 24 horas -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) muestra cero pérdidas y cero errores durante 24h -- [ ] Enlaces sin drenar después de un rodaje limpio +### Fase 5: Período de Prueba de Enlaces +- [ ] Todos los enlaces drenados para un período de prueba de 24 horas +- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) muestra cero pérdida y cero errores durante 24h +- [ ] Enlaces restaurados después de una prueba limpia ### Fase 6: Verificación y Activación - [ ] `doublezero device list` muestra su dispositivo (con `max_users = 0`) - [ ] `doublezero link list` muestra sus enlaces -- [ ] Los logs del Agente de Configuración muestran extracciones de configuración exitosas -- [ ] Los logs del Agente de Telemetría muestran presentaciones de métricas exitosas -- [ ] **Coordinar con DZ/Malbec Labs** para ejecutar una prueba de conectividad (conectar, recibir rutas, enrutar sobre DZ) -- [ ] Después de que la prueba pase, establecer `max_users` en 96 mediante `doublezero device update` +- [ ] Los registros del Config Agent muestran obtenciones de configuración exitosas +- [ ] Los registros del Telemetry Agent muestran envíos de métricas exitosos +- [ ] **Coordinar con DZ/Malbec Labs** para ejecutar prueba de conectividad (conectar, recibir rutas, enrutar por DZ) +- [ ] Después de pasar la prueba, establecer `max_users` a 96 mediante `doublezero device update` --- ## Obtener Ayuda -Como parte de la incorporación, DZF le añadirá a los canales Slack de contribuidores: +Como parte de la incorporación, DZF le añadirá a los canales de Slack para contribuidores: | Canal | Propósito | -|---------|---------| -| **#dz-contributor-announcements** | Comunicaciones oficiales de DZF y Malbec Labs — actualizaciones de CLI/agentes, cambios importantes, anuncios de seguridad. Monitoree para actualizaciones críticas; haga preguntas en los hilos. | -| **#dz-contributor-incidents** | Eventos no planificados que afectan el servicio. Los incidentes se publican automáticamente a través de la API/formulario web con severidad y dispositivos/enlaces afectados. La discusión y solución de problemas ocurre en los hilos. | -| **#dz-contributor-maintenance** | Actividades de mantenimiento planificadas (actualizaciones, reparaciones). Programadas a través de la API/formulario web con tiempos de inicio/fin planificados. Discusión en hilos. | +|-------|-----------| +| **#dz-contributor-announcements** | Comunicaciones oficiales de DZF y Malbec Labs — actualizaciones de CLI/agentes, cambios incompatibles, anuncios de seguridad. Monitoree para actualizaciones críticas; haga preguntas en hilos. | +| **#dz-contributor-incidents** | Eventos no planificados con impacto en el servicio. Los incidentes se publican automáticamente a través de la API/formulario web con severidad y dispositivos/enlaces afectados. La discusión y resolución de problemas ocurre en hilos. | +| **#dz-contributor-maintenance** | Actividades de mantenimiento planificadas (actualizaciones, reparaciones). Programadas a través de la API/formulario web con horarios de inicio/fin planificados. Discusión en hilos. | | **#dz-contributor-ops** | Discusión abierta para todos los contribuidores — preguntas operativas, ayuda con CLI, compartir runbooks y playbooks. | -También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo de su organización. +También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo para su organización. --- -## Reglas de Prefijo DZ +## Reglas de Prefijos DZ !!! warning "Crítico: Uso del Pool de Prefijos DZ" - El pool de prefijos DZ que proporciona es **gestionado por el protocolo DoubleZero para la asignación de IP**. + El pool de prefijos DZ que usted proporciona es **gestionado por el protocolo DoubleZero para la asignación de IP**. - **Cómo se usan los prefijos DZ:** + **Cómo se utilizan los prefijos DZ:** - **Primera IP**: Reservada para su dispositivo (asignada a la interfaz Loopback100) - **IPs restantes**: Asignadas a tipos específicos de usuarios que se conectan a su DZD: @@ -91,21 +97,21 @@ También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo d - Publicadores multicast - **Usuarios IBRL**: NO consumen de este pool (usan su propia IP pública) - **NO puede usar estas direcciones para:** + **NO PUEDE usar estas direcciones para:** - - Su propio equipo de red + - Su propio equipamiento de red - Enlaces punto a punto en interfaces DIA - Interfaces de gestión - Cualquier infraestructura fuera del protocolo DZ **Requisitos:** - - Deben ser direcciones IPv4 **globalmente enrutables (públicas)** + - Deben ser direcciones IPv4 **enrutables globalmente (públicas)** - Los rangos de IP privados (10.x, 172.16-31.x, 192.168.x) son rechazados por el contrato inteligente - - **Tamaño mínimo: /29** (8 direcciones), se prefieren prefijos más grandes (por ejemplo, /28, /27) - - Todo el bloque debe estar disponible - no preasigne ninguna dirección + - **Tamaño mínimo: /29** (8 direcciones), se prefieren prefijos más grandes (ej., /28, /27) + - El bloque completo debe estar disponible - no pre-asigne ninguna dirección - Si necesita direcciones para su propio equipo (IPs de interfaz DIA, gestión, etc.), use un **pool de direcciones separado**. + Si necesita direcciones para su propio equipamiento (IPs de interfaz DIA, gestión, etc.), use un **pool de direcciones separado**. --- @@ -114,17 +120,18 @@ También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo d ¿Nuevo en DoubleZero? Aquí están los términos esenciales (consulte el [Glosario completo](glossary.md)): | Término | Definición | -|------|------------| -| **DZD** | Dispositivo DoubleZero - su switch físico Arista que ejecuta los agentes DZ | -| **DZX** | Exchange DoubleZero - punto de interconexión metropolitana donde los contribuidores se conectan entre sí | -| **CYOA** | Elige Tu Propia Aventura - método de conectividad de usuarios (GREOverDIA, GREOverFabric, etc.) | -| **DIA** | Acceso Directo a Internet - conectividad a internet requerida por todos los DZDs para el controlador y la telemetría, comúnmente usado como tipo CYOA para la conectividad de usuarios en dispositivos de borde/híbridos | -| **Enlace WAN** | Enlace entre sus propios DZDs (mismo contribuidor) | -| **Enlace DZX** | Enlace al DZD de otro contribuidor (requiere aceptación mutua) | -| **Agente de Configuración** | Consulta el controlador, aplica la configuración a su DZD | -| **Agente de Telemetría** | Recopila métricas de latencia/pérdida TWAMP, las envía al ledger onchain | -| **Clave de Servicio** | Su clave de identidad de contribuidor para operaciones CLI | -| **Clave de Editor de Métricas** | Clave para firmar presentaciones de telemetría onchain | +|---------|------------| +| **DZD** | DoubleZero Device - su switch Arista físico ejecutando agentes DZ | +| **DZX** | DoubleZero Exchange - punto de interconexión metropolitana donde los contribuidores establecen peering | +| **CYOA** | Choose Your Own Adventure - método de conectividad de usuario (GREOverDIA, GREOverFabric, etc.) | +| **DIA** | Direct Internet Access - conectividad a internet requerida por todos los DZDs para el controlador y telemetría, comúnmente usado como tipo CYOA para conectividad de usuarios en dispositivos edge/híbridos | +| **WAN Link** | Enlace entre sus propios DZDs (mismo contribuidor) | +| **DZX Link** | Enlace al DZD de otro contribuidor (requiere aceptación mutua) | +| **Config Agent** | Consulta el controlador, aplica configuración a su DZD | +| **Telemetry Agent** | Recopila métricas de latencia/pérdida TWAMP, las envía al ledger onchain | +| **Service Key** | Su clave de identidad de contribuidor para operaciones con CLI | +| **Metrics Publisher Key** | Clave para firmar envíos de telemetría onchain | +| **Rewards Manager Key** | Clave que controla qué billeteras reciben sus recompensas | --- @@ -133,23 +140,25 @@ También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo d ## Estructura de la Documentación | Guía | Descripción | -|-------|-------------| +|------|-------------| | [Requisitos y Arquitectura](contribute.md) | Especificaciones de hardware, arquitectura de red, opciones de ancho de banda | | [Aprovisionamiento de Dispositivos](contribute-provisioning.md) | Paso a paso: claves → acceso al repositorio → dispositivo → enlaces → agentes | +| [Gestión de Recompensas](contribute-rewards.md) | Configurar las billeteras que reciben sus recompensas 2Z | | [Operaciones](contribute-operations.md) | Actualizaciones de agentes, gestión de enlaces, monitoreo | -| [Glosario](glossary.md) | Toda la terminología DoubleZero definida | +| [Despliegue de Geoprobe](contribute-geolocation.md) | Despliegue y configuración de agentes geoProbe para geolocalización | +| [Glosario](glossary.md) | Toda la terminología de DoubleZero definida | --- -## Conceptos de Red para No Ingenieros de Red +## Conceptos Básicos de Red para No Ingenieros de Redes Si no tiene experiencia en ingeniería de redes, aquí hay una introducción a los conceptos utilizados en esta documentación: ### Direccionamiento IP -- **Dirección IPv4**: Un identificador único para un dispositivo en una red (por ejemplo, `192.168.1.1`) +- **Dirección IPv4**: Un identificador único para un dispositivo en una red (ej., `192.168.1.1`) - **Notación CIDR** (`/29`, `/24`): Indica el tamaño de la subred. `/29` = 8 direcciones, `/24` = 256 direcciones -- **IP pública**: Enrutable en internet; **IP privada**: Solo redes internas (10.x, 172.16-31.x, 192.168.x) +- **IP Pública**: Enrutable en internet; **IP Privada**: Solo redes internas (10.x, 172.16-31.x, 192.168.x) ### Capas de Red @@ -159,18 +168,18 @@ Si no tiene experiencia en ingeniería de redes, aquí hay una introducción a l ### Términos Comunes -- **MTU**: Unidad Máxima de Transmisión - tamaño máximo de paquete (típicamente 9000 bytes para enlaces WAN) -- **VLAN**: LAN Virtual - separa lógicamente el tráfico en infraestructura compartida -- **VRF**: Enrutamiento y Reenvío Virtual - aísla tablas de enrutamiento en el mismo dispositivo -- **BGP**: Protocolo de Puerta de Enlace de Borde - intercambio de rutas entre redes -- **GRE**: Encapsulación de Enrutamiento Genérico - protocolo de tunelización para redes superpuestas -- **TWAMP**: Protocolo de Medición Activa Bidireccional - mide latencia/pérdida entre dispositivos +- **MTU**: Maximum Transmission Unit - tamaño máximo de paquete (típicamente 9000 bytes para enlaces WAN) +- **VLAN**: Virtual LAN - separa lógicamente el tráfico en infraestructura compartida +- **VRF**: Virtual Routing and Forwarding - aísla tablas de enrutamiento en el mismo dispositivo +- **BGP**: Border Gateway Protocol - intercambio de rutas entre redes +- **GRE**: Generic Routing Encapsulation - protocolo de tunelización para redes overlay +- **TWAMP**: Two-Way Active Measurement Protocol - mide latencia/pérdida entre dispositivos ### Específico de DoubleZero -- **Onchain**: En DoubleZero, los registros de dispositivos, las configuraciones de enlaces y la telemetría se registran en el ledger DoubleZero, haciendo que el estado de la red sea transparente y verificable por todos los participantes -- **Controlador**: Servicio que deriva la configuración de DZD a partir del estado onchain en el ledger DoubleZero +- **Onchain**: En DoubleZero, los registros de dispositivos, configuraciones de enlaces y telemetría se registran en el ledger de DoubleZero — haciendo que el estado de la red sea transparente y verificable por todos los participantes +- **Controlador**: Servicio que deriva la configuración del DZD a partir del estado onchain en el ledger de DoubleZero --- -¿Listo para comenzar? Empiece con [Requisitos y Arquitectura](contribute.md). +¿Listo para comenzar? Empiece con [Requisitos y Arquitectura](contribute.md). \ No newline at end of file diff --git a/docs/contribute-overview.fr.md b/docs/contribute-overview.fr.md index b799d74..70ccbba 100644 --- a/docs/contribute-overview.fr.md +++ b/docs/contribute-overview.fr.md @@ -1,176 +1,185 @@ -# Documentation Contributeur -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Aperçu et liste de vérification d'intégration pour devenir contributeur au réseau DoubleZero. +--- +# Documentation pour les contributeurs !!! info "Terminologie" - Nouveau sur DoubleZero ? Consultez le [Glossaire](glossary.md) pour les définitions des termes clés comme [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) et [CYOA](glossary.md#cyoa-choose-your-own-adventure). + Vous découvrez DoubleZero ? Consultez le [Glossaire](glossary.md) pour les définitions des termes clés comme [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) et [CYOA](glossary.md#cyoa-choose-your-own-adventure). -Bienvenue dans la documentation des contributeurs DoubleZero. Cette section couvre tout ce dont vous avez besoin pour devenir un contributeur réseau. +Bienvenue dans la documentation pour les contributeurs DoubleZero. Cette section couvre tout ce dont vous avez besoin pour devenir contributeur au réseau. -!!! tip "Intéressé à devenir un contributeur réseau ?" - Consultez la page [Exigences et Architecture](contribute.md) pour comprendre le matériel, la bande passante et la connectivité nécessaires pour contribuer au réseau DoubleZero. +!!! tip "Intéressé à devenir contributeur au réseau ?" + Consultez la page [Exigences et architecture](contribute.md) pour comprendre le matériel, la bande passante et la connectivité nécessaires pour contribuer au réseau DoubleZero. --- -## Checklist d'Intégration +## Liste de vérification d'intégration -Utilisez cette checklist pour suivre votre progression. **Tous les éléments doivent être complétés avant que votre contribution soit techniquement opérationnelle.** +Utilisez cette liste de vérification pour suivre votre progression. **Tous les éléments doivent être complétés avant que votre contribution soit techniquement opérationnelle.** ### Phase 1 : Prérequis -- [ ] CLI DoubleZero installée sur un serveur de gestion +- [ ] CLI DoubleZero installé sur un serveur de gestion - [ ] Matériel procuré et conforme aux [exigences](contribute.md#hardware-requirements) -- [ ] Espace rack et alimentation disponibles en centre de données (4U, 4KW recommandé) +- [ ] Espace rack et alimentation disponibles dans le centre de données (voir [Rack et alimentation](contribute.md#rack-power-requirements)) - [ ] DZD physiquement installé avec connectivité de gestion -- [ ] Bloc IPv4 public alloué pour le protocole DZ (**voir [Règles du Préfixe DZ](#dz-prefix-rules)**) - -### Phase 2 : Configuration du Compte -- [ ] Keypair de service générée (`doublezero keygen`) -- [ ] Keypair d'éditeur de métriques générée -- [ ] Clé de service soumise à DZF pour autorisation -- [ ] Compte contributeur créé on-chain (vérifier avec `doublezero contributor list`) +- [ ] Bloc IPv4 public alloué pour le protocole DZ (**voir [Règles de préfixe DZ](#regles-de-prefixe-dz)**) + +### Phase 2 : Configuration du compte +- [ ] Paire de clés de service générée (`doublezero keygen`) +- [ ] Paire de clés de publication de métriques générée +- [ ] Portefeuille du gestionnaire de récompenses créé et alimenté avec ~0.01 SOL +- [ ] Clé de service, clé du gestionnaire de récompenses et nom d'utilisateur GitHub soumis à la DZF (clés publiques uniquement) +- [ ] Compte contributeur créé onchain (vérifier avec `doublezero contributor list`) +- [ ] Clé du gestionnaire de récompenses enregistrée onchain par la DZF - [ ] Accès accordé au dépôt [malbeclabs/contributors](https://github.com/malbeclabs/contributors) +- [ ] Portefeuilles destinataires et pourcentages configurés (**voir [Gestion des récompenses](contribute-rewards.md)**) +- [ ] Chaque portefeuille destinataire dispose d'un compte de jetons 2Z -### Phase 3 : Provisionnement du Dispositif -- [ ] Configuration de base du dispositif appliquée (depuis le dépôt contributeurs) -- [ ] Dispositif créé on-chain (`doublezero device create`) -- [ ] Interfaces du dispositif enregistrées +### Phase 3 : Provisionnement de l'appareil +- [ ] Configuration de base de l'appareil appliquée (depuis le dépôt contributors) +- [ ] Appareil créé onchain (`doublezero device create`) +- [ ] Interfaces de l'appareil enregistrées - [ ] Interfaces loopback créées (Loopback255 vpnv4, Loopback256 ipv4) -- [ ] Interfaces CYOA/DIA configurées (si dispositif edge/hybride) +- [ ] Interfaces CYOA/DIA configurées (si appareil edge/hybride) -### Phase 4 : Établissement des Liens & Installation des Agents +### Phase 4 : Établissement des liens et installation de l'agent - [ ] Liens WAN créés (le cas échéant) - [ ] Lien DZX créé (statut : `requested`) - [ ] Lien DZX accepté par le contributeur pair -- [ ] Config Agent installé et en cours d'exécution +- [ ] Config Agent installé et en fonctionnement - [ ] Config Agent recevant la configuration du contrôleur -- [ ] Telemetry Agent installé et en cours d'exécution -- [ ] Éditeur de métriques enregistré on-chain +- [ ] Telemetry Agent installé et en fonctionnement +- [ ] Éditeur de métriques enregistré onchain - [ ] Soumissions de télémétrie visibles sur le registre -### Phase 5 : Burn-in du Lien -- [ ] Tous les liens drainés pendant la période de burn-in de 24 heures -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) montre zéro perte et zéro erreur pendant 24h -- [ ] Liens non drainés après un burn-in propre +### Phase 5 : Rodage des liens +- [ ] Tous les liens vidés pour une période de rodage de 24 heures +- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) affiche zéro perte et zéro erreur pendant 24h +- [ ] Liens réactivés après un rodage propre -### Phase 6 : Vérification & Activation -- [ ] `doublezero device list` affiche votre dispositif (avec `max_users = 0`) +### Phase 6 : Vérification et activation +- [ ] `doublezero device list` affiche votre appareil (avec `max_users = 0`) - [ ] `doublezero link list` affiche vos liens -- [ ] Les logs du Config Agent montrent des récupérations de configuration réussies -- [ ] Les logs du Telemetry Agent montrent des soumissions de métriques réussies -- [ ] **Coordonner avec DZ/Malbec Labs** pour exécuter un test de connectivité (connexion, réception des routes, routage sur DZ) -- [ ] Après que le test est réussi, définir `max_users` à 96 via `doublezero device update` +- [ ] Les journaux du Config Agent montrent des extractions de configuration réussies +- [ ] Les journaux du Telemetry Agent montrent des soumissions de métriques réussies +- [ ] **Coordonner avec DZ/Malbec Labs** pour exécuter un test de connectivité (connexion, réception de routes, routage via DZ) +- [ ] Après la réussite du test, définir `max_users` à 96 via `doublezero device update` --- -## Obtenir de l'Aide +## Obtenir de l'aide -Dans le cadre de l'intégration, DZF vous ajoutera aux canaux Slack des contributeurs : +Dans le cadre de l'intégration, la DZF vous ajoutera aux canaux Slack des contributeurs : | Canal | Objectif | -|---------|---------| -| **#dz-contributor-announcements** | Communications officielles de DZF et Malbec Labs — mises à niveau CLI/agent, changements majeurs, annonces de sécurité. Surveiller pour les mises à jour critiques ; poser des questions dans les fils de discussion. | -| **#dz-contributor-incidents** | Événements imprévus ayant un impact sur le service. Les incidents sont publiés automatiquement via l'API/formulaire web avec la gravité et les dispositifs/liens affectés. Discussion et résolution de problèmes dans les fils de discussion. | -| **#dz-contributor-maintenance** | Activités de maintenance planifiées (mises à niveau, réparations). Planifiées via l'API/formulaire web avec les heures de début/fin prévues. Discussion dans les fils de discussion. | -| **#dz-contributor-ops** | Discussion ouverte pour tous les contributeurs — questions opérationnelles, aide CLI, partage de runbooks et de playbooks. | +|-------|----------| +| **#dz-contributor-announcements** | Communications officielles de la DZF et Malbec Labs — mises à jour CLI/agents, changements majeurs, annonces de sécurité. Surveillez les mises à jour critiques ; posez vos questions dans les fils de discussion. | +| **#dz-contributor-incidents** | Événements non planifiés impactant le service. Les incidents sont publiés automatiquement via l'API/formulaire web avec la sévérité et les appareils/liens affectés. Les discussions et le dépannage se font dans les fils. | +| **#dz-contributor-maintenance** | Activités de maintenance planifiées (mises à jour, réparations). Programmées via l'API/formulaire web avec les heures de début/fin prévues. Discussions dans les fils. | +| **#dz-contributor-ops** | Discussion ouverte pour tous les contributeurs — questions opérationnelles, aide CLI, partage de runbooks et playbooks. | -Vous obtiendrez également un **canal privé DZ/Malbec Labs** pour le support direct de votre organisation. +Vous obtiendrez également un **canal privé DZ/Malbec Labs** pour un support direct pour votre organisation. --- -## Règles du Préfixe DZ +## Règles de préfixe DZ -!!! warning "Critique : Utilisation du Pool de Préfixes DZ" - Le pool de préfixes DZ que vous fournissez est **géré par le protocole DoubleZero pour l'allocation IP**. +!!! warning "Critique : Utilisation du pool de préfixes DZ" + Le pool de préfixes DZ que vous fournissez est **géré par le protocole DoubleZero pour l'allocation d'adresses IP**. **Comment les préfixes DZ sont utilisés :** - - **Premier IP** : Réservé pour votre dispositif (attribué à l'interface Loopback100) - - **IP Restants** : Alloués à des types d'utilisateurs spécifiques se connectant à votre DZD : + - **Première IP** : Réservée pour votre appareil (assignée à l'interface Loopback100) + - **IP restantes** : Allouées à des types d'utilisateurs spécifiques se connectant à votre DZD : - Utilisateurs `IBRLWithAllocatedIP` - Utilisateurs `EdgeFiltering` - Éditeurs multicast - - **Utilisateurs IBRL** : N'utilisent PAS ce pool (ils utilisent leur propre IP public) + - **Utilisateurs IBRL** : Ne consomment PAS de ce pool (ils utilisent leur propre IP publique) **Vous NE POUVEZ PAS utiliser ces adresses pour :** - Votre propre équipement réseau - - Liens point à point sur les interfaces DIA - - Interfaces de gestion + - Les liens point à point sur les interfaces DIA + - Les interfaces de gestion - Toute infrastructure en dehors du protocole DZ **Exigences :** - - Doivent être des adresses IPv4 **globalement routables (publiques)** - - Les plages IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le contrat intelligent - - **Taille minimale : /29** (8 adresses), préfixes plus grands préférés (p. ex., /28, /27) - - Le bloc entier doit être disponible - ne pas pré-allouer d'adresses + - Doivent être des adresses IPv4 **routables globalement (publiques)** + - Les plages d'IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le contrat intelligent + - **Taille minimale : /29** (8 adresses), les préfixes plus grands sont préférés (par ex., /28, /27) + - L'ensemble du bloc doit être disponible — ne pré-allouez aucune adresse Si vous avez besoin d'adresses pour votre propre équipement (IP d'interface DIA, gestion, etc.), utilisez un **pool d'adresses séparé**. --- -## Référence Rapide : Termes Clés +## Référence rapide : Termes clés -Nouveau sur DoubleZero ? Voici les termes essentiels (voir le [Glossaire complet](glossary.md)) : +Vous découvrez DoubleZero ? Voici les termes essentiels (voir le [Glossaire complet](glossary.md)) : | Terme | Définition | -|------|------------| -| **DZD** | DoubleZero Device - votre commutateur Arista physique exécutant les agents DZ | -| **DZX** | DoubleZero Exchange - point d'interconnexion métropolitain où les contributeurs font du peering | +|-------|------------| +| **DZD** | DoubleZero Device - votre commutateur physique Arista exécutant les agents DZ | +| **DZX** | DoubleZero Exchange - point d'interconnexion métropolitain où les contributeurs s'appairent | | **CYOA** | Choose Your Own Adventure - méthode de connectivité utilisateur (GREOverDIA, GREOverFabric, etc.) | -| **DIA** | Direct Internet Access - connectivité internet requise par tous les DZD pour le contrôleur et la télémétrie, couramment utilisée comme type CYOA pour la connectivité utilisateur sur les dispositifs edge/hybrides | -| **Lien WAN** | Lien entre vos propres DZD (même contributeur) | -| **Lien DZX** | Lien vers le DZD d'un autre contributeur (nécessite une acceptation mutuelle) | +| **DIA** | Direct Internet Access - connectivité internet requise par tous les DZD pour le contrôleur et la télémétrie, couramment utilisé comme type CYOA pour la connectivité utilisateur sur les appareils edge/hybrides | +| **WAN Link** | Lien entre vos propres DZD (même contributeur) | +| **DZX Link** | Lien vers le DZD d'un autre contributeur (nécessite une acceptation mutuelle) | | **Config Agent** | Interroge le contrôleur, applique la configuration à votre DZD | -| **Telemetry Agent** | Collecte les métriques de latence/perte TWAMP, soumet au registre on-chain | -| **Clé de Service** | Votre clé d'identité de contributeur pour les opérations CLI | -| **Clé d'Éditeur de Métriques** | Clé pour signer les soumissions de télémétrie on-chain | +| **Telemetry Agent** | Collecte les métriques de latence/perte TWAMP, les soumet au registre onchain | +| **Service Key** | Votre clé d'identité de contributeur pour les opérations CLI | +| **Metrics Publisher Key** | Clé pour signer les soumissions de télémétrie onchain | +| **Rewards Manager Key** | Clé qui contrôle quels portefeuilles reçoivent vos récompenses | --- --- -## Structure de la Documentation +## Structure de la documentation | Guide | Description | |-------|-------------| -| [Exigences et Architecture](contribute.md) | Spécifications matérielles, architecture réseau, options de bande passante | -| [Provisionnement des Dispositifs](contribute-provisioning.md) | Étape par étape : clés → accès au dépôt → dispositif → liens → agents | -| [Opérations](contribute-operations.md) | Mises à niveau des agents, gestion des liens, surveillance | +| [Exigences et architecture](contribute.md) | Spécifications matérielles, architecture réseau, options de bande passante | +| [Provisionnement de l'appareil](contribute-provisioning.md) | Étape par étape : clés → accès au dépôt → appareil → liens → agents | +| [Gestion des récompenses](contribute-rewards.md) | Configuration des portefeuilles qui reçoivent vos récompenses 2Z | +| [Opérations](contribute-operations.md) | Mises à jour des agents, gestion des liens, surveillance | +| [Déploiement de Geoprobe](contribute-geolocation.md) | Déploiement et configuration des agents geoProbe pour la géolocalisation | | [Glossaire](glossary.md) | Toute la terminologie DoubleZero définie | --- -## Bases du Réseau pour les Non-Ingénieurs Réseau +## Bases du réseau pour les non-ingénieurs réseau -Si vous n'avez pas de formation en ingénierie réseau, voici une introduction aux concepts utilisés dans cette documentation : +Si vous ne venez pas d'un milieu d'ingénierie réseau, voici une introduction aux concepts utilisés dans cette documentation : ### Adressage IP -- **Adresse IPv4** : Un identifiant unique pour un dispositif sur un réseau (p. ex., `192.168.1.1`) +- **Adresse IPv4** : Un identifiant unique pour un appareil sur un réseau (par ex., `192.168.1.1`) - **Notation CIDR** (`/29`, `/24`) : Indique la taille du sous-réseau. `/29` = 8 adresses, `/24` = 256 adresses -- **IP Public** : Routable sur internet ; **IP Privé** : Réseaux internes uniquement (10.x, 172.16-31.x, 192.168.x) +- **IP publique** : Routable sur internet ; **IP privée** : Réseaux internes uniquement (10.x, 172.16-31.x, 192.168.x) -### Couches Réseau +### Couches réseau - **Couche 1 (Physique)** : Câbles, optiques, longueurs d'onde -- **Couche 2 (Liaison de Données)** : Commutateurs, VLANs, adresses MAC +- **Couche 2 (Liaison de données)** : Commutateurs, VLAN, adresses MAC - **Couche 3 (Réseau)** : Routeurs, adresses IP, protocoles de routage -### Termes Courants +### Termes courants -- **MTU** : Maximum Transmission Unit - taille maximale des paquets (typiquement 9000 octets pour les liens WAN) +- **MTU** : Maximum Transmission Unit - taille maximale de paquet (généralement 9000 octets pour les liens WAN) - **VLAN** : Virtual LAN - sépare logiquement le trafic sur une infrastructure partagée -- **VRF** : Virtual Routing and Forwarding - isole les tables de routage sur le même dispositif -- **BGP** : Border Gateway Protocol - échange de routes inter-réseau -- **GRE** : Generic Routing Encapsulation - protocole de tunneling pour les réseaux overlay -- **TWAMP** : Two-Way Active Measurement Protocol - mesure la latence/perte entre les dispositifs +- **VRF** : Virtual Routing and Forwarding - isole les tables de routage sur le même appareil +- **BGP** : Border Gateway Protocol - échange de routes inter-réseaux +- **GRE** : Generic Routing Encapsulation - protocole de tunnellisation pour les réseaux overlay +- **TWAMP** : Two-Way Active Measurement Protocol - mesure la latence/perte entre les appareils ### Spécifique à DoubleZero -- **On-chain** : Dans DoubleZero, les enregistrements de dispositifs, les configurations de liens et la télémétrie sont enregistrés sur le registre DoubleZero — rendant l'état du réseau transparent et vérifiable par tous les participants -- **Contrôleur** : Service qui dérive la configuration DZD à partir de l'état on-chain sur le registre DoubleZero +- **Onchain** : Dans DoubleZero, les enregistrements d'appareils, les configurations de liens et la télémétrie sont enregistrés sur le registre DoubleZero — rendant l'état du réseau transparent et vérifiable par tous les participants +- **Contrôleur** : Service qui dérive la configuration du DZD à partir de l'état onchain sur le registre DoubleZero --- -Prêt à commencer ? Commencez par [Exigences et Architecture](contribute.md). +Prêt à commencer ? Démarrez avec [Exigences et architecture](contribute.md). \ No newline at end of file diff --git a/docs/contribute-overview.it.md b/docs/contribute-overview.it.md index b3672d7..afc5673 100644 --- a/docs/contribute-overview.it.md +++ b/docs/contribute-overview.it.md @@ -1,91 +1,97 @@ -# Documentazione Contributori -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Panoramica e checklist di onboarding per diventare un contributor della rete DoubleZero. +--- +# Documentazione per i Contributor !!! info "Terminologia" - Nuovo a DoubleZero? Consulta il [Glossario](glossary.md) per le definizioni dei termini chiave come [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) e [CYOA](glossary.md#cyoa-choose-your-own-adventure). + Sei nuovo su DoubleZero? Consulta il [Glossario](glossary.md) per le definizioni dei termini chiave come [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) e [CYOA](glossary.md#cyoa-choose-your-own-adventure). -Benvenuto alla documentazione per i contributori DoubleZero. Questa sezione copre tutto ciò di cui hai bisogno per diventare un contributore di rete. +Benvenuto nella documentazione per i contributor di DoubleZero. Questa sezione copre tutto ciò che serve per diventare un contributor della rete. -!!! tip "Interessato a diventare un contributore di rete?" - Consulta la pagina [Requisiti e Architettura](contribute.md) per comprendere l'hardware, la larghezza di banda e la connettività necessaria per contribuire alla rete DoubleZero. +!!! tip "Sei interessato a diventare un contributor della rete?" + Consulta la pagina [Requisiti e Architettura](contribute.md) per comprendere l'hardware, la larghezza di banda e la connettività necessari per contribuire alla rete DoubleZero. --- -## Lista di Controllo per l'Onboarding +## Checklist di Onboarding -Usa questa lista di controllo per monitorare i tuoi progressi. **Tutti gli elementi devono essere completati prima che il tuo contributo sia tecnicamente operativo.** +Usa questa checklist per monitorare i tuoi progressi. **Tutti gli elementi devono essere completati prima che il tuo contributo sia tecnicamente operativo.** ### Fase 1: Prerequisiti -- [ ] CLI DoubleZero installata su un server di gestione -- [ ] Hardware acquistato e conforme ai [requisiti](contribute.md#hardware-requirements) -- [ ] Spazio rack e alimentazione disponibili nel data center (4U, 4KW raccomandati) -- [ ] DZD installato fisicamente con connettività di gestione -- [ ] Blocco IPv4 pubblico allocato per il protocollo DZ (**vedi [Regole DZ Prefix](#dz-prefix-rules)**) - -### Fase 2: Configurazione Account -- [ ] Keypair del servizio generato (`doublezero keygen`) -- [ ] Keypair del metrics publisher generato -- [ ] Service key inviata a DZF per l'autorizzazione -- [ ] Account contributore creato onchain (verifica con `doublezero contributor list`) +- [ ] CLI di DoubleZero installata su un server di gestione +- [ ] Hardware procurato e conforme ai [requisiti](contribute.md#hardware-requirements) +- [ ] Spazio rack e alimentazione disponibili nel data center (vedi [Rack e Alimentazione](contribute.md#rack-power-requirements)) +- [ ] DZD fisicamente installato con connettività di gestione +- [ ] Blocco IPv4 pubblico allocato per il protocollo DZ (**vedi [Regole per i Prefissi DZ](#regole-per-i-prefissi-dz)**) + +### Fase 2: Configurazione dell'Account +- [ ] Coppia di chiavi del servizio generata (`doublezero keygen`) +- [ ] Coppia di chiavi del metrics publisher generata +- [ ] Wallet del rewards manager creato e finanziato con ~0.01 SOL +- [ ] Chiave del servizio, chiave del rewards manager e username GitHub inviati a DZF (solo chiavi pubbliche) +- [ ] Account contributor creato onchain (verificare con `doublezero contributor list`) +- [ ] Chiave del rewards manager registrata onchain da DZF - [ ] Accesso concesso al repository [malbeclabs/contributors](https://github.com/malbeclabs/contributors) +- [ ] Wallet destinatari e percentuali configurati (**vedi [Gestione delle Ricompense](contribute-rewards.md)**) +- [ ] Ogni wallet destinatario ha un token account 2Z ### Fase 3: Provisioning del Dispositivo -- [ ] Configurazione base del dispositivo applicata (dal repository dei contributori) +- [ ] Configurazione base del dispositivo applicata (dal repo contributors) - [ ] Dispositivo creato onchain (`doublezero device create`) - [ ] Interfacce del dispositivo registrate - [ ] Interfacce loopback create (Loopback255 vpnv4, Loopback256 ipv4) -- [ ] Interfacce CYOA/DIA configurate (se dispositivo edge/hybrid) +- [ ] Interfacce CYOA/DIA configurate (se dispositivo edge/ibrido) -### Fase 4: Creazione Link e Installazione Agent -- [ ] WAN link creati (se applicabile) -- [ ] DZX link creato (stato: `requested`) -- [ ] DZX link accettato dal contributore peer +### Fase 4: Creazione dei Link e Installazione dell'Agent +- [ ] Link WAN creati (se applicabile) +- [ ] Link DZX creato (stato: `requested`) +- [ ] Link DZX accettato dal contributor peer - [ ] Config Agent installato e in esecuzione - [ ] Config Agent che riceve la configurazione dal controller - [ ] Telemetry Agent installato e in esecuzione - [ ] Metrics publisher registrato onchain -- [ ] Invii di telemetria visibili sul registro +- [ ] Invii di telemetria visibili sul ledger -### Fase 5: Burn-in del Link -- [ ] Tutti i link drenati per il periodo di burn-in di 24 ore -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) mostra zero perdite e zero errori per 24 ore -- [ ] Link ri-attivati dopo il burn-in pulito +### Fase 5: Burn-in dei Link +- [ ] Tutti i link in drain per un periodo di burn-in di 24 ore +- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) mostra zero perdite e zero errori per 24h +- [ ] Link rimossi dal drain dopo un burn-in pulito ### Fase 6: Verifica e Attivazione - [ ] `doublezero device list` mostra il tuo dispositivo (con `max_users = 0`) - [ ] `doublezero link list` mostra i tuoi link - [ ] I log del Config Agent mostrano pull di configurazione riusciti - [ ] I log del Telemetry Agent mostrano invii di metriche riusciti -- [ ] **Coordina con DZ/Malbec Labs** per eseguire un test di connettività (connetti, ricevi route, instrada su DZ) -- [ ] Dopo che il test è superato, imposta `max_users` a 96 tramite `doublezero device update` +- [ ] **Coordinarsi con DZ/Malbec Labs** per eseguire il test di connettività (connessione, ricezione delle rotte, routing su DZ) +- [ ] Dopo il superamento del test, impostare `max_users` a 96 tramite `doublezero device update` --- ## Ottenere Aiuto -Come parte dell'onboarding, DZF ti aggiungerà ai canali Slack per i contributori: +Come parte dell'onboarding, DZF ti aggiungerà ai canali Slack per i contributor: | Canale | Scopo | |--------|-------| -| **#dz-contributor-announcements** | Comunicazioni ufficiali da DZF e Malbec Labs — aggiornamenti CLI/agent, modifiche importanti, annunci di sicurezza. Monitora per aggiornamenti critici; fai domande nei thread. | -| **#dz-contributor-incidents** | Eventi non pianificati che impattano il servizio. Gli incidenti vengono pubblicati automaticamente tramite API/web form con gravità e dispositivi/link interessati. La discussione e la risoluzione dei problemi avvengono nei thread. | -| **#dz-contributor-maintenance** | Attività di manutenzione pianificate (aggiornamenti, riparazioni). Pianificate tramite API/web form con orari di inizio/fine previsti. Discussione nei thread. | -| **#dz-contributor-ops** | Discussione aperta per tutti i contributori — domande operative, aiuto CLI, condivisione di runbook e playbook. | +| **#dz-contributor-announcements** | Comunicazioni ufficiali da DZF e Malbec Labs — aggiornamenti CLI/agent, breaking changes, annunci di sicurezza. Monitora per aggiornamenti critici; fai domande nei thread. | +| **#dz-contributor-incidents** | Eventi non pianificati con impatto sul servizio. Gli incidenti vengono pubblicati automaticamente tramite API/form web con severità e dispositivi/link interessati. Discussione e troubleshooting nei thread. | +| **#dz-contributor-maintenance** | Attività di manutenzione pianificata (aggiornamenti, riparazioni). Programmate tramite API/form web con orari di inizio/fine previsti. Discussione nei thread. | +| **#dz-contributor-ops** | Discussione aperta per tutti i contributor — domande operative, aiuto sulla CLI, condivisione di runbook e playbook. | Riceverai anche un **canale privato DZ/Malbec Labs** per supporto diretto alla tua organizzazione. --- -## Regole DZ Prefix +## Regole per i Prefissi DZ -!!! warning "Critico: Utilizzo del Pool DZ Prefix" - Il pool di DZ prefix che fornisci è **gestito dal protocollo DoubleZero per l'allocazione IP**. +!!! warning "Critico: Utilizzo del Pool di Prefissi DZ" + Il pool di prefissi DZ che fornisci è **gestito dal protocollo DoubleZero per l'allocazione degli IP**. - **Come vengono utilizzati i DZ prefix:** + **Come vengono utilizzati i prefissi DZ:** - - **Primo IP**: Riservato al tuo dispositivo (assegnato all'interfaccia Loopback100) - - **IP rimanenti**: Allocati a tipi specifici di utenti che si connettono al tuo DZD: + - **Primo IP**: Riservato per il tuo dispositivo (assegnato all'interfaccia Loopback100) + - **IP rimanenti**: Allocati a specifici tipi di utenti che si connettono al tuo DZD: - Utenti `IBRLWithAllocatedIP` - Utenti `EdgeFiltering` - Publisher multicast @@ -94,37 +100,38 @@ Riceverai anche un **canale privato DZ/Malbec Labs** per supporto diretto alla t **NON puoi usare questi indirizzi per:** - Le tue apparecchiature di rete - - Link punto-a-punto su interfacce DIA + - Link punto-punto sulle interfacce DIA - Interfacce di gestione - Qualsiasi infrastruttura al di fuori del protocollo DZ **Requisiti:** - Devono essere indirizzi IPv4 **globalmente instradabili (pubblici)** - - Gli intervalli IP privati (10.x, 172.16-31.x, 192.168.x) vengono rifiutati dallo smart contract - - **Dimensione minima: /29** (8 indirizzi), preferibili prefissi più grandi (es. /28, /27) + - I range IP privati (10.x, 172.16-31.x, 192.168.x) vengono rifiutati dallo smart contract + - **Dimensione minima: /29** (8 indirizzi), prefissi più grandi preferiti (es., /28, /27) - L'intero blocco deve essere disponibile - non pre-allocare alcun indirizzo - Se hai bisogno di indirizzi per le tue apparecchiature (IP interfacce DIA, gestione, ecc.), usa un **pool di indirizzi separato**. + Se hai bisogno di indirizzi per le tue apparecchiature (IP delle interfacce DIA, gestione, ecc.), usa un **pool di indirizzi separato**. --- ## Riferimento Rapido: Termini Chiave -Nuovo a DoubleZero? Ecco i termini essenziali (vedi il [Glossario completo](glossary.md)): +Sei nuovo su DoubleZero? Ecco i termini essenziali (vedi il [Glossario completo](glossary.md)): | Termine | Definizione | -|---------|-------------| -| **DZD** | DoubleZero Device - il tuo switch fisico Arista che esegue gli agenti DZ | -| **DZX** | DoubleZero Exchange - punto di interconnessione metro dove i contributori si collegano | +|---------|------------| +| **DZD** | DoubleZero Device - il tuo switch fisico Arista che esegue gli agent DZ | +| **DZX** | DoubleZero Exchange - punto di interconnessione metro dove i contributor fanno peering | | **CYOA** | Choose Your Own Adventure - metodo di connettività utente (GREOverDIA, GREOverFabric, ecc.) | -| **DIA** | Direct Internet Access - connettività internet richiesta da tutti i DZD per controller e telemetria, comunemente usata come tipo CYOA per la connettività utente su dispositivi edge/hybrid | -| **WAN Link** | Link tra i tuoi DZD (stesso contributore) | -| **DZX Link** | Link verso il DZD di un altro contributore (richiede accettazione reciproca) | +| **DIA** | Direct Internet Access - connettività internet richiesta da tutti i DZD per controller e telemetria, comunemente usata come tipo CYOA per la connettività utente su dispositivi edge/ibridi | +| **WAN Link** | Link tra i tuoi DZD (stesso contributor) | +| **DZX Link** | Link verso il DZD di un altro contributor (richiede accettazione reciproca) | | **Config Agent** | Interroga il controller, applica la configurazione al tuo DZD | -| **Telemetry Agent** | Raccoglie metriche di latenza/perdita TWAMP, le invia al registro onchain | -| **Service Key** | La tua chiave di identità contributore per le operazioni CLI | +| **Telemetry Agent** | Raccoglie metriche di latenza/perdita TWAMP, le invia al ledger onchain | +| **Service Key** | La tua chiave di identità come contributor per le operazioni CLI | | **Metrics Publisher Key** | Chiave per firmare gli invii di telemetria onchain | +| **Rewards Manager Key** | Chiave che controlla quali wallet ricevono le tue ricompense | --- @@ -135,19 +142,21 @@ Nuovo a DoubleZero? Ecco i termini essenziali (vedi il [Glossario completo](glos | Guida | Descrizione | |-------|-------------| | [Requisiti e Architettura](contribute.md) | Specifiche hardware, architettura di rete, opzioni di larghezza di banda | -| [Provisioning Dispositivo](contribute-provisioning.md) | Passo per passo: chiavi → accesso repo → dispositivo → link → agenti | -| [Operazioni](contribute-operations.md) | Aggiornamenti agent, gestione link, monitoraggio | -| [Glossario](glossary.md) | Tutta la terminologia DoubleZero definita | +| [Provisioning del Dispositivo](contribute-provisioning.md) | Passo dopo passo: chiavi → accesso al repo → dispositivo → link → agent | +| [Gestione delle Ricompense](contribute-rewards.md) | Configurazione dei wallet che ricevono le tue ricompense 2Z | +| [Operazioni](contribute-operations.md) | Aggiornamenti degli agent, gestione dei link, monitoraggio | +| [Deployment di Geoprobe](contribute-geolocation.md) | Deploy e configurazione degli agent geoProbe per la geolocalizzazione | +| [Glossario](glossary.md) | Tutta la terminologia di DoubleZero definita | --- -## Nozioni di Base di Rete per Non-Ingegneri di Rete +## Fondamenti di Rete per Non-Ingegneri di Rete -Se non hai un background ingegneristico di rete, ecco un primer sui concetti utilizzati in questa documentazione: +Se non hai un background di ingegneria di rete, ecco un'introduzione ai concetti utilizzati in questa documentazione: ### Indirizzamento IP -- **Indirizzo IPv4**: Un identificatore univoco per un dispositivo su una rete (es. `192.168.1.1`) +- **Indirizzo IPv4**: Un identificatore univoco per un dispositivo su una rete (es., `192.168.1.1`) - **Notazione CIDR** (`/29`, `/24`): Indica la dimensione della subnet. `/29` = 8 indirizzi, `/24` = 256 indirizzi - **IP Pubblico**: Instradabile su internet; **IP Privato**: Solo reti interne (10.x, 172.16-31.x, 192.168.x) @@ -159,18 +168,18 @@ Se non hai un background ingegneristico di rete, ecco un primer sui concetti uti ### Termini Comuni -- **MTU**: Maximum Transmission Unit - dimensione massima del pacchetto (tipicamente 9000 byte per link WAN) +- **MTU**: Maximum Transmission Unit - dimensione massima del pacchetto (tipicamente 9000 byte per i link WAN) - **VLAN**: Virtual LAN - separa logicamente il traffico su infrastruttura condivisa - **VRF**: Virtual Routing and Forwarding - isola le tabelle di routing sullo stesso dispositivo -- **BGP**: Border Gateway Protocol - scambio di route tra reti +- **BGP**: Border Gateway Protocol - scambio di rotte tra reti - **GRE**: Generic Routing Encapsulation - protocollo di tunneling per reti overlay - **TWAMP**: Two-Way Active Measurement Protocol - misura latenza/perdita tra dispositivi -### Specifico di DoubleZero +### Specifici di DoubleZero -- **Onchain**: In DoubleZero, le registrazioni dei dispositivi, le configurazioni dei link e la telemetria vengono registrate nel registro DoubleZero — rendendo lo stato della rete trasparente e verificabile da tutti i partecipanti -- **Controller**: Servizio che deriva la configurazione DZD dallo stato onchain nel registro DoubleZero +- **Onchain**: In DoubleZero, le registrazioni dei dispositivi, le configurazioni dei link e la telemetria vengono registrate sul ledger di DoubleZero — rendendo lo stato della rete trasparente e verificabile da tutti i partecipanti +- **Controller**: Servizio che deriva la configurazione del DZD dallo stato onchain sul ledger di DoubleZero --- -Pronto per iniziare? Inizia con [Requisiti e Architettura](contribute.md). +Pronto per iniziare? Parti da [Requisiti e Architettura](contribute.md). \ No newline at end of file diff --git a/docs/contribute-overview.ja.md b/docs/contribute-overview.ja.md index 7dbe847..0139a91 100644 --- a/docs/contribute-overview.ja.md +++ b/docs/contribute-overview.ja.md @@ -1,130 +1,137 @@ -# コントリビューターのドキュメント -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: DoubleZeroネットワークコントリビューターになるための概要とオンボーディングチェックリスト。 +--- +# コントリビュータードキュメント -!!! info "用語" - DoubleZeroを初めて利用しますか？[用語集](glossary.md)で[DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange)、[CYOA](glossary.md#cyoa-choose-your-own-adventure)などの主要な用語の定義を確認してください。 +!!! info "用語について" + DoubleZeroは初めてですか？[用語集](glossary.md)で[DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange)、[CYOA](glossary.md#cyoa-choose-your-own-adventure)などの主要な用語の定義をご覧ください。 -DoubleZeroコントリビューターのドキュメントへようこそ。このセクションではネットワークコントリビューターになるために必要なすべてをカバーしています。 +DoubleZeroコントリビュータードキュメントへようこそ。このセクションでは、ネットワークコントリビューターになるために必要なすべてを網羅しています。 -!!! tip "ネットワークコントリビューターになることに興味がありますか？" - [要件とアーキテクチャ](contribute.md)ページを確認して、DoubleZeroネットワークへの貢献に必要なハードウェア、帯域幅、接続性を理解してください。 +!!! tip "ネットワークコントリビューターに興味がありますか？" + [要件とアーキテクチャ](contribute.md)ページを確認し、DoubleZeroネットワークへの貢献に必要なハードウェア、帯域幅、接続性について理解してください。 --- ## オンボーディングチェックリスト -このチェックリストを使って進捗を追跡してください。**貢献が技術的に運用可能になる前にすべての項目を完了する必要があります。** - -### フェーズ1：前提条件 -- [ ] 管理サーバーにDoubleZero CLIをインストール -- [ ] ハードウェアを調達し、[要件](contribute.md#hardware-requirements)を満たしていることを確認 -- [ ] データセンターのラックスペースと電力を確保（4U、4KW推奨） -- [ ] DZDを物理的にインストールし、管理接続が可能な状態にする -- [ ] DZプロトコル用のパブリックIPv4ブロックを割り当て（**[DZプレフィックスルール](#dz-prefix-rules)を参照**） - -### フェーズ2：アカウントのセットアップ -- [ ] サービスキーペアを生成（`doublezero keygen`） -- [ ] メトリクスパブリッシャーキーペアを生成 -- [ ] サービスキーをDZFに提出して承認を取得 -- [ ] コントリビューターアカウントをオンチェーンで作成（`doublezero contributor list`で確認） -- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors)リポジトリへのアクセスを取得 - -### フェーズ3：デバイスプロビジョニング -- [ ] ベースデバイス設定を適用（contributorsリポジトリより） -- [ ] デバイスをオンチェーンで作成（`doublezero device create`） -- [ ] デバイスインターフェースを登録 -- [ ] ループバックインターフェースを作成（Loopback255 vpnv4、Loopback256 ipv4） -- [ ] CYOA/DIAインターフェースを設定（エッジ/ハイブリッドデバイスの場合） - -### フェーズ4：リンク確立とエージェントインストール -- [ ] WANリンクを作成（該当する場合） -- [ ] DZXリンクを作成（ステータス：`requested`） -- [ ] ピアコントリビューターがDZXリンクを承認 -- [ ] Config Agentをインストールして実行 -- [ ] Config Agentがコントローラーから設定を受信 -- [ ] Telemetry Agentをインストールして実行 -- [ ] メトリクスパブリッシャーをオンチェーンで登録 -- [ ] テレメトリ送信がレジャーで確認可能 - -### フェーズ5：リンクのバーンイン -- [ ] すべてのリンクを24時間バーンイン期間中ドレイン -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz)で24時間のゼロロスおよびゼロエラーを確認 -- [ ] クリーンなバーンイン後にリンクのドレインを解除 - -### フェーズ6：検証とアクティベーション -- [ ] `doublezero device list`でデバイスが表示される（`max_users = 0`で） +このチェックリストを使用して進捗を追跡してください。**すべての項目が完了しないと、コントリビューションは技術的に稼働状態になりません。** + +### フェーズ1: 前提条件 +- [ ] DoubleZero CLIを管理サーバーにインストール済み +- [ ] ハードウェアを調達し、[要件](contribute.md#hardware-requirements)を満たしている +- [ ] データセンターのラックスペースと電源が利用可能（[ラックと電源](contribute.md#rack-power-requirements)を参照） +- [ ] DZDが物理的に設置され、管理接続が確立されている +- [ ] DZプロトコル用のパブリックIPv4ブロックが割り当て済み（**[DZプレフィックスルール](#dz-prefix-rules)**を参照） + +### フェーズ2: アカウントセットアップ +- [ ] サービスキーペアを生成済み（`doublezero keygen`） +- [ ] メトリクスパブリッシャーキーペアを生成済み +- [ ] リワードマネージャーウォレットを作成し、約0.01 SOLで入金済み +- [ ] サービスキー、リワードマネージャーキー、GitHubユーザー名をDZFに提出済み（公開鍵のみ） +- [ ] コントリビューターアカウントがオンチェーンに作成済み（`doublezero contributor list`で確認） +- [ ] リワードマネージャーキーがDZFによりオンチェーンに登録済み +- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors)リポジトリへのアクセスが付与済み +- [ ] 受取ウォレットと配分割合を設定済み（**[リワード管理](contribute-rewards.md)**を参照） +- [ ] 各受取ウォレットに2Zトークンアカウントがある + +### フェーズ3: デバイスプロビジョニング +- [ ] 基本デバイス設定を適用済み（contributorsリポジトリから） +- [ ] デバイスをオンチェーンに作成済み（`doublezero device create`） +- [ ] デバイスインターフェースを登録済み +- [ ] ループバックインターフェースを作成済み（Loopback255 vpnv4、Loopback256 ipv4） +- [ ] CYOA/DIAインターフェースを設定済み（エッジ/ハイブリッドデバイスの場合） + +### フェーズ4: リンク確立とエージェントインストール +- [ ] WANリンクを作成済み（該当する場合） +- [ ] DZXリンクを作成済み（ステータス: `requested`） +- [ ] DZXリンクがピアコントリビューターにより承認済み +- [ ] Config Agentをインストールし、稼働中 +- [ ] Config Agentがコントローラーから設定を受信している +- [ ] Telemetry Agentをインストールし、稼働中 +- [ ] メトリクスパブリッシャーをオンチェーンに登録済み +- [ ] テレメトリの送信がレジャーで確認可能 + +### フェーズ5: リンクバーンイン +- [ ] すべてのリンクを24時間のバーンイン期間のためにドレイン済み +- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz)で24時間にわたりゼロロス・ゼロエラーが表示されている +- [ ] クリーンなバーンイン後にリンクのドレインを解除済み + +### フェーズ6: 検証とアクティベーション +- [ ] `doublezero device list`でデバイスが表示される（`max_users = 0`） - [ ] `doublezero link list`でリンクが表示される -- [ ] Config Agentのログで設定プルの成功を確認 -- [ ] Telemetry Agentのログでメトリクス送信の成功を確認 -- [ ] **DZ/Malbec Labsと協力**して接続テストを実行（接続、ルート受信、DZ経由のルーティング） +- [ ] Config Agentのログに設定プルの成功が記録されている +- [ ] Telemetry Agentのログにメトリクス送信の成功が記録されている +- [ ] **DZ/Malbec Labsと連携**して接続テストを実施（接続、ルート受信、DZ経由のルーティング） - [ ] テスト合格後、`doublezero device update`で`max_users`を96に設定 --- -## ヘルプの取得 +## サポートの利用 -オンボーディングの一環として、DZFはコントリビューターのSlackチャンネルに追加します： +オンボーディングの一環として、DZFがコントリビューターSlackチャンネルに追加します： | チャンネル | 目的 | |---------|---------| -| **#dz-contributor-announcements** | DZFとMalbec Labsからの公式通知 — CLI/エージェントのアップグレード、重大な変更、セキュリティアナウンス。重要な更新を監視し、スレッドで質問してください。 | -| **#dz-contributor-incidents** | 予定外のサービス影響イベント。インシデントはAPI/ウェブフォームを通じて深刻度と影響を受けるデバイス/リンクとともに自動投稿されます。スレッドで議論とトラブルシューティングが行われます。 | -| **#dz-contributor-maintenance** | 計画されたメンテナンス活動（アップグレード、修理）。API/ウェブフォームを通じて計画された開始/終了時間とともにスケジュールされます。スレッドで議論が行われます。 | -| **#dz-contributor-ops** | すべてのコントリビューターのオープンディスカッション — 運用上の質問、CLIのヘルプ、ランブックとプレイブックの共有。 | +| **#dz-contributor-announcements** | DZFおよびMalbec Labsからの公式コミュニケーション — CLI/エージェントのアップグレード、破壊的変更、セキュリティアナウンス。重要なアップデートを監視し、質問はスレッドで行ってください。 | +| **#dz-contributor-incidents** | 計画外のサービス影響イベント。インシデントはAPI/ウェブフォーム経由で重大度と影響を受けるデバイス/リンクとともに自動的に投稿されます。議論とトラブルシューティングはスレッドで行います。 | +| **#dz-contributor-maintenance** | 計画的なメンテナンス活動（アップグレード、修理）。API/ウェブフォーム経由で計画開始/終了時刻とともにスケジュールされます。議論はスレッドで行います。 | +| **#dz-contributor-ops** | すべてのコントリビューター向けのオープンディスカッション — 運用に関する質問、CLIヘルプ、ランブックやプレイブックの共有。 | -また、組織への直接サポートのために**プライベートDZ/Malbec Labsチャンネル**も提供されます。 +また、組織向けの直接サポートのための**プライベートDZ/Malbec Labsチャンネル**も提供されます。 --- ## DZプレフィックスルール -!!! warning "重要：DZプレフィックスプールの使用" - 提供するDZプレフィックスプールは**DoubleZeroプロトコルがIP割り当てを管理**します。 +!!! warning "重要: DZプレフィックスプールの使用について" + 提供するDZプレフィックスプールは、**IP割り当てのためにDoubleZeroプロトコルが管理します**。 **DZプレフィックスの使用方法：** - - **最初のIP**：デバイス用に予約（Loopback100インターフェースに割り当て） - - **残りのIP**：DZDに接続する特定のユーザータイプに割り当て： - - `IBRLWithAllocatedIP`ユーザー - - `EdgeFiltering`ユーザー + - **最初のIP**: デバイス用に予約（Loopback100インターフェースに割り当て） + - **残りのIP**: DZDに接続する特定のユーザータイプに割り当て： + - `IBRLWithAllocatedIP` ユーザー + - `EdgeFiltering` ユーザー - マルチキャストパブリッシャー - - **IBRLユーザー**：このプールを消費しません（独自のパブリックIPを使用） + - **IBRLユーザー**: このプールからは消費しません（独自のパブリックIPを使用） - **これらのアドレスは以下に使用できません：** + **以下の用途には使用できません：** - - 自社のネットワーク機器 + - 自身のネットワーク機器 - DIAインターフェースのポイントツーポイントリンク - 管理インターフェース - - DZプロトコル外のインフラ + - DZプロトコル外のあらゆるインフラストラクチャ **要件：** - - **グローバルにルーティング可能（パブリック）**なIPv4アドレスである必要があります - - プライベートIP範囲（10.x、172.16-31.x、192.168.x）はスマートコントラクトで拒否されます - - **最小サイズ：/29**（8アドレス）、大きなプレフィックス推奨（例：/28、/27） + - **グローバルにルーティング可能な（パブリック）** IPv4アドレスである必要があります + - プライベートIPレンジ（10.x、172.16-31.x、192.168.x）はスマートコントラクトにより拒否されます + - **最小サイズ: /29**（8アドレス）、より大きなプレフィックスが推奨されます（例: /28、/27） - ブロック全体が利用可能である必要があります - アドレスを事前に割り当てないでください - 自社の機器用にアドレスが必要な場合（DIAインターフェースIP、管理など）は、**別のアドレスプール**を使用してください。 + 自身の機器用のアドレス（DIAインターフェースIP、管理用など）が必要な場合は、**別のアドレスプール**を使用してください。 --- -## クイックリファレンス：主要用語 +## クイックリファレンス: 主要用語 -DoubleZeroを初めて利用しますか？以下は必須の用語です（[完全な用語集](glossary.md)を参照）： +DoubleZeroは初めてですか？以下が基本的な用語です（[完全な用語集](glossary.md)を参照）： | 用語 | 定義 | |------|------------| -| **DZD** | DoubleZeroデバイス - DZエージェントを実行する物理Aristaスイッチ | -| **DZX** | DoubleZero Exchange - コントリビューターがピアするメトロ相互接続ポイント | -| **CYOA** | Choose Your Own Adventure - ユーザー接続方式（GREOverDIA、GREOverFabricなど） | -| **DIA** | Direct Internet Access - すべてのDZDがコントローラーとテレメトリに必要とするインターネット接続、エッジ/ハイブリッドデバイスでのユーザー接続のCYOAタイプとしてよく使用される | -| **WANリンク** | 自社のDZD間のリンク（同一コントリビューター） | -| **DZXリンク** | 別のコントリビューターのDZDへのリンク（相互承認が必要） | -| **Config Agent** | コントローラーをポーリングし、DZDに設定を適用する | -| **Telemetry Agent** | TWAMPレイテンシ/ロスメトリクスを収集し、オンチェーンレジャーに送信する | -| **サービスキー** | CLI操作のためのコントリビューターアイデンティティキー | -| **メトリクスパブリッシャーキー** | テレメトリ送信をオンチェーンで署名するためのキー | +| **DZD** | DoubleZero Device - DZエージェントを実行する物理的なArista スイッチ | +| **DZX** | DoubleZero Exchange - コントリビューター同士がピアリングするメトロ相互接続ポイント | +| **CYOA** | Choose Your Own Adventure - ユーザー接続方法（GREOverDIA、GREOverFabricなど） | +| **DIA** | Direct Internet Access - コントローラーとテレメトリのためにすべてのDZDに必要なインターネット接続。エッジ/ハイブリッドデバイスではユーザー接続用のCYOAタイプとしてもよく使用されます | +| **WAN Link** | 自身のDZD間のリンク（同一コントリビューター） | +| **DZX Link** | 別のコントリビューターのDZDへのリンク（相互承認が必要） | +| **Config Agent** | コントローラーをポーリングし、DZDに設定を適用するエージェント | +| **Telemetry Agent** | TWAMPレイテンシ/ロスメトリクスを収集し、オンチェーンレジャーに送信するエージェント | +| **Service Key** | CLI操作用のコントリビューターIDキー | +| **Metrics Publisher Key** | オンチェーンのテレメトリ送信に署名するためのキー | +| **Rewards Manager Key** | リワードを受け取るウォレットを管理するキー | --- @@ -135,42 +142,44 @@ DoubleZeroを初めて利用しますか？以下は必須の用語です（[完 | ガイド | 説明 | |-------|-------------| | [要件とアーキテクチャ](contribute.md) | ハードウェア仕様、ネットワークアーキテクチャ、帯域幅オプション | -| [デバイスプロビジョニング](contribute-provisioning.md) | ステップバイステップ：キー → リポジトリアクセス → デバイス → リンク → エージェント | -| [運用](contribute-operations.md) | エージェントのアップグレード、リンク管理、監視 | -| [用語集](glossary.md) | すべてのDoubleZero用語の定義 | +| [デバイスプロビジョニング](contribute-provisioning.md) | ステップバイステップ: キー → リポジトリアクセス → デバイス → リンク → エージェント | +| [リワード管理](contribute-rewards.md) | 2Zリワードを受け取るウォレットの設定 | +| [運用](contribute-operations.md) | エージェントアップグレード、リンク管理、モニタリング | +| [Geoプローブデプロイメント](contribute-geolocation.md) | ジオロケーション用のgeoProbeエージェントのデプロイと設定 | +| [用語集](glossary.md) | DoubleZeroの全用語定義 | --- -## ネットワークエンジニア以外向けのネットワーク基礎 +## ネットワークエンジニア以外の方向けのネットワーク基礎 -ネットワークエンジニアのバックグラウンドがない場合は、このドキュメントで使用される概念の入門として以下をご覧ください： +ネットワークエンジニアリングのバックグラウンドがない方向けに、このドキュメントで使用される概念の入門ガイドを紹介します： ### IPアドレッシング -- **IPv4アドレス**：ネットワーク上のデバイスの一意の識別子（例：`192.168.1.1`） -- **CIDR表記**（`/29`、`/24`）：サブネットサイズを示します。`/29` = 8アドレス、`/24` = 256アドレス -- **パブリックIP**：インターネットでルーティング可能；**プライベートIP**：内部ネットワークのみ（10.x、172.16-31.x、192.168.x） +- **IPv4アドレス**: ネットワーク上のデバイスの一意な識別子（例: `192.168.1.1`） +- **CIDR表記**（`/29`、`/24`）: サブネットのサイズを示します。`/29` = 8アドレス、`/24` = 256アドレス +- **パブリックIP**: インターネット上でルーティング可能；**プライベートIP**: 内部ネットワーク専用（10.x、172.16-31.x、192.168.x） -### ネットワーク層 +### ネットワークレイヤー -- **レイヤー1（物理）**：ケーブル、光学機器、波長 -- **レイヤー2（データリンク）**：スイッチ、VLAN、MACアドレス -- **レイヤー3（ネットワーク）**：ルーター、IPアドレス、ルーティングプロトコル +- **レイヤー1（物理層）**: ケーブル、光学機器、波長 +- **レイヤー2（データリンク層）**: スイッチ、VLAN、MACアドレス +- **レイヤー3（ネットワーク層）**: ルーター、IPアドレス、ルーティングプロトコル ### 一般的な用語 -- **MTU**：Maximum Transmission Unit - 最大パケットサイズ（WANリンクでは通常9000バイト） -- **VLAN**：Virtual LAN - 共有インフラ上のトラフィックを論理的に分離する -- **VRF**：Virtual Routing and Forwarding - 同じデバイス上でルーティングテーブルを分離する -- **BGP**：Border Gateway Protocol - ネットワーク間のルート交換 -- **GRE**：Generic Routing Encapsulation - オーバーレイネットワークのためのトンネリングプロトコル -- **TWAMP**：Two-Way Active Measurement Protocol - デバイス間のレイテンシ/ロスを測定する +- **MTU**: Maximum Transmission Unit（最大転送単位）- 最大パケットサイズ（WANリンクでは通常9000バイト） +- **VLAN**: Virtual LAN - 共有インフラストラクチャ上でトラフィックを論理的に分離 +- **VRF**: Virtual Routing and Forwarding - 同一デバイス上でルーティングテーブルを分離 +- **BGP**: Border Gateway Protocol - ネットワーク間のルート交換プロトコル +- **GRE**: Generic Routing Encapsulation - オーバーレイネットワーク用のトンネリングプロトコル +- **TWAMP**: Two-Way Active Measurement Protocol - デバイス間のレイテンシ/ロスを測定するプロトコル -### DoubleZero固有 +### DoubleZero固有の用語 -- **オンチェーン**：DoubleZeroでは、デバイス登録、リンク設定、テレメトリがDoubleZeroレジャーに記録されます — ネットワーク状態がすべての参加者に対して透明で検証可能になります -- **コントローラー**：DoubleZeroレジャーのオンチェーン状態からDZD設定を導出するサービス +- **オンチェーン**: DoubleZeroでは、デバイスの登録、リンク設定、テレメトリがDoubleZeroレジャーに記録されます — ネットワーク状態をすべての参加者が透過的かつ検証可能にします +- **コントローラー**: DoubleZeroレジャー上のオンチェーン状態からDZDの設定を導出するサービス --- -準備ができましたか？[要件とアーキテクチャ](contribute.md)から始めてください。 +始める準備はできましたか？[要件とアーキテクチャ](contribute.md)から始めましょう。 \ No newline at end of file diff --git a/docs/contribute-overview.ko.md b/docs/contribute-overview.ko.md index 6e5d56b..2e3daa9 100644 --- a/docs/contribute-overview.ko.md +++ b/docs/contribute-overview.ko.md @@ -1,130 +1,137 @@ -# 기여자 문서 -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: DoubleZero 네트워크 기여자가 되기 위한 개요 및 온보딩 체크리스트. +--- +# 기여자 문서 !!! info "용어" - DoubleZero가 처음이신가요? [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange), [CYOA](glossary.md#cyoa-choose-your-own-adventure)와 같은 핵심 용어의 정의는 [용어집](glossary.md)을 참조하세요. + DoubleZero가 처음이신가요? [용어집](glossary.md)에서 [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange), [CYOA](glossary.md#cyoa-choose-your-own-adventure) 등 주요 용어의 정의를 확인하세요. -DoubleZero 기여자 문서에 오신 것을 환영합니다. 이 섹션에서는 네트워크 기여자가 되기 위해 필요한 모든 것을 다룹니다. +DoubleZero 기여자 문서에 오신 것을 환영합니다. 이 섹션에서는 네트워크 기여자가 되기 위해 필요한 모든 내용을 다룹니다. !!! tip "네트워크 기여자가 되고 싶으신가요?" - DoubleZero 네트워크에 기여하는 데 필요한 하드웨어, 대역폭 및 연결성을 이해하려면 [요구사항 및 아키텍처](contribute.md) 페이지를 검토하세요. + [요구사항 및 아키텍처](contribute.md) 페이지를 검토하여 DoubleZero 네트워크에 기여하는 데 필요한 하드웨어, 대역폭 및 연결 요건을 파악하세요. --- ## 온보딩 체크리스트 -이 체크리스트를 사용하여 진행 상황을 추적하세요. **기여가 기술적으로 운영되기 전에 모든 항목을 완료해야 합니다.** +이 체크리스트를 사용하여 진행 상황을 추적하세요. **모든 항목이 완료되어야 기여가 기술적으로 운영 가능합니다.** -### 단계 1: 사전 요구사항 -- [ ] 관리 서버에 DoubleZero CLI 설치 -- [ ] 하드웨어 구매 및 [요구사항](contribute.md#hardware-requirements) 충족 -- [ ] 데이터 센터 랙 공간 및 전원 사용 가능 (4U, 4KW 권장) +### 1단계: 사전 요건 +- [ ] 관리 서버에 DoubleZero CLI 설치 완료 +- [ ] 하드웨어 조달 및 [요구사항](contribute.md#hardware-requirements) 충족 확인 +- [ ] 데이터 센터 랙 공간 및 전원 확보 ([랙 및 전원](contribute.md#rack-power-requirements) 참조) - [ ] DZD 물리적 설치 및 관리 연결 완료 -- [ ] DZ 프로토콜을 위한 공개 IPv4 블록 할당 (**[DZ 프리픽스 규칙](#dz-prefix-rules) 참조**) +- [ ] DZ 프로토콜용 공인 IPv4 블록 할당 (**[DZ 프리픽스 규칙](#dz-프리픽스-규칙) 참조**) -### 단계 2: 계정 설정 -- [ ] 서비스 키쌍 생성 (`doublezero keygen`) -- [ ] 메트릭스 발행자 키쌍 생성 -- [ ] 인증을 위해 DZF에 서비스 키 제출 +### 2단계: 계정 설정 +- [ ] 서비스 키페어 생성 (`doublezero keygen`) +- [ ] 메트릭 퍼블리셔 키페어 생성 +- [ ] 리워드 매니저 지갑 생성 및 ~0.01 SOL 충전 +- [ ] 서비스 키, 리워드 매니저 키 및 GitHub 사용자명을 DZF에 제출 (공개 키만) - [ ] 온체인 기여자 계정 생성 (`doublezero contributor list`로 확인) -- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 저장소 접근 권한 부여 - -### 단계 3: 장치 프로비저닝 -- [ ] 장치에 기본 구성 적용 (기여자 저장소에서) -- [ ] 온체인 장치 생성 (`doublezero device create`) -- [ ] 장치 인터페이스 등록 +- [ ] DZF에 의해 온체인 리워드 매니저 키 등록 완료 +- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 리포지토리 접근 권한 부여 +- [ ] 수령 지갑 및 비율 설정 (**[리워드 관리](contribute-rewards.md) 참조**) +- [ ] 각 수령 지갑에 2Z 토큰 계정 보유 + +### 3단계: 디바이스 프로비저닝 +- [ ] 기본 디바이스 설정 적용 (contributors 리포지토리에서) +- [ ] 온체인 디바이스 생성 (`doublezero device create`) +- [ ] 디바이스 인터페이스 등록 - [ ] 루프백 인터페이스 생성 (Loopback255 vpnv4, Loopback256 ipv4) -- [ ] CYOA/DIA 인터페이스 구성 (엣지/하이브리드 장치인 경우) +- [ ] CYOA/DIA 인터페이스 설정 (엣지/하이브리드 디바이스인 경우) -### 단계 4: 링크 설정 및 에이전트 설치 +### 4단계: 링크 설정 및 에이전트 설치 - [ ] WAN 링크 생성 (해당하는 경우) - [ ] DZX 링크 생성 (상태: `requested`) -- [ ] 상대방 기여자가 DZX 링크 수락 +- [ ] 피어 기여자의 DZX 링크 수락 - [ ] Config Agent 설치 및 실행 -- [ ] Config Agent가 컨트롤러에서 구성 수신 +- [ ] Config Agent가 컨트롤러로부터 설정 수신 - [ ] Telemetry Agent 설치 및 실행 -- [ ] 메트릭스 발행자 온체인 등록 -- [ ] 레저에서 텔레메트리 제출 확인 +- [ ] 온체인 메트릭 퍼블리셔 등록 +- [ ] 원장에서 텔레메트리 제출 확인 가능 -### 단계 5: 링크 번인 -- [ ] 24시간 번인 기간 동안 모든 링크 드레인 상태 유지 -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz)에서 24시간 동안 손실 및 오류 0 확인 -- [ ] 클린 번인 완료 후 링크 드레인 해제 +### 5단계: 링크 번인 +- [ ] 24시간 번인 기간 동안 모든 링크 드레인 +- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz)에서 24시간 동안 손실 제로 및 오류 제로 확인 +- [ ] 클린 번인 후 링크 드레인 해제 -### 단계 6: 검증 및 활성화 -- [ ] `doublezero device list`에서 장치 확인 (`max_users = 0` 상태) +### 6단계: 검증 및 활성화 +- [ ] `doublezero device list`에서 디바이스 확인 (`max_users = 0`) - [ ] `doublezero link list`에서 링크 확인 -- [ ] Config Agent 로그에서 성공적인 구성 가져오기 확인 -- [ ] Telemetry Agent 로그에서 성공적인 메트릭스 제출 확인 -- [ ] **DZ/Malbec Labs와 조율**하여 연결 테스트 실행 (연결, 경로 수신, DZ를 통한 라우팅) +- [ ] Config Agent 로그에서 설정 풀 성공 확인 +- [ ] Telemetry Agent 로그에서 메트릭 제출 성공 확인 +- [ ] **DZ/Malbec Labs와 조율**하여 연결 테스트 실행 (연결, 라우트 수신, DZ를 통한 라우팅) - [ ] 테스트 통과 후 `doublezero device update`를 통해 `max_users`를 96으로 설정 --- ## 도움 받기 -온보딩의 일환으로 DZF가 기여자 Slack 채널에 추가해 드립니다: +온보딩 과정에서 DZF가 기여자 Slack 채널에 추가해 드립니다: | 채널 | 목적 | |---------|---------| -| **#dz-contributor-announcements** | DZF 및 Malbec Labs의 공식 커뮤니케이션 — CLI/에이전트 업데이트, 주요 변경 사항, 보안 공지. 중요 업데이트 모니터링. 스레드에서 질문 가능. | -| **#dz-contributor-incidents** | 서비스에 영향을 미치는 계획되지 않은 이벤트. 인시던트는 심각도 및 영향받는 장치/링크와 함께 API/웹 양식을 통해 자동으로 게시됩니다. 스레드에서 토론 및 문제 해결. | -| **#dz-contributor-maintenance** | 계획된 유지보수 활동 (업그레이드, 수리). API/웹 양식을 통해 예상 시작/종료 시간과 함께 예약됩니다. 스레드에서 토론. | -| **#dz-contributor-ops** | 모든 기여자를 위한 공개 토론 — 운영 질문, CLI 도움, 런북 및 플레이북 공유. | +| **#dz-contributor-announcements** | DZF 및 Malbec Labs의 공식 커뮤니케이션 — CLI/에이전트 업그레이드, 호환성 변경, 보안 공지. 중요한 업데이트를 모니터링하고 스레드에서 질문하세요. | +| **#dz-contributor-incidents** | 계획되지 않은 서비스 영향 이벤트. 인시던트는 API/웹 양식을 통해 심각도 및 영향받는 디바이스/링크와 함께 자동으로 게시됩니다. 토론 및 트러블슈팅은 스레드에서 진행됩니다. | +| **#dz-contributor-maintenance** | 계획된 유지보수 활동 (업그레이드, 수리). API/웹 양식을 통해 계획된 시작/종료 시간과 함께 예약됩니다. 토론은 스레드에서 진행됩니다. | +| **#dz-contributor-ops** | 모든 기여자를 위한 오픈 토론 — 운영 질문, CLI 도움, 런북 및 플레이북 공유. | -귀하의 조직을 위한 직접 지원을 위한 **DZ/Malbec Labs 전용 채널**도 받게 됩니다. +또한 조직에 대한 직접 지원을 위한 **비공개 DZ/Malbec Labs 채널**도 제공됩니다. --- ## DZ 프리픽스 규칙 !!! warning "중요: DZ 프리픽스 풀 사용" - 제공하는 DZ 프리픽스 풀은 **IP 할당을 위해 DoubleZero 프로토콜이 관리**합니다. + 제공하는 DZ 프리픽스 풀은 **IP 할당을 위해 DoubleZero 프로토콜이 관리합니다**. - **DZ 프리픽스가 사용되는 방식:** + **DZ 프리픽스 사용 방식:** - - **첫 번째 IP**: 장치용으로 예약됨 (Loopback100 인터페이스에 할당) - - **나머지 IP**: DZD에 연결하는 특정 유형의 사용자에게 할당: + - **첫 번째 IP**: 디바이스용으로 예약 (Loopback100 인터페이스에 할당) + - **나머지 IP**: DZD에 연결하는 특정 사용자 유형에 할당: - `IBRLWithAllocatedIP` 사용자 - `EdgeFiltering` 사용자 - - 멀티캐스트 발행자 - - **IBRL 사용자**: 이 풀을 소비하지 않음 (자신의 공개 IP 사용) + - 멀티캐스트 퍼블리셔 + - **IBRL 사용자**: 이 풀에서 소비하지 않음 (자체 공인 IP 사용) **다음 용도로 사용할 수 없습니다:** - - 자신의 네트워크 장비 - - DIA 인터페이스의 지점간 링크 + - 자체 네트워크 장비 + - DIA 인터페이스의 포인트-투-포인트 링크 - 관리 인터페이스 - DZ 프로토콜 외부의 모든 인프라 **요구사항:** - - 전 세계적으로 라우팅 가능한(공개) IPv4 주소여야 합니다 - - 사설 IP 범위(10.x, 172.16-31.x, 192.168.x)는 스마트 계약에서 거부됩니다 + - **전역 라우팅 가능한 (공인)** IPv4 주소여야 함 + - 사설 IP 범위 (10.x, 172.16-31.x, 192.168.x)는 스마트 컨트랙트에 의해 거부됨 - **최소 크기: /29** (8개 주소), 더 큰 프리픽스 권장 (예: /28, /27) - - 전체 블록이 사용 가능해야 합니다 — 어떤 주소도 사전 할당하지 마세요 + - 전체 블록이 사용 가능해야 함 - 어떤 주소도 사전 할당하지 마세요 - 자신의 장비(DIA 인터페이스 IP, 관리 등)를 위한 주소가 필요한 경우 **별도의 주소 풀**을 사용하세요. + 자체 장비(DIA 인터페이스 IP, 관리 등)에 주소가 필요한 경우 **별도의 주소 풀**을 사용하세요. --- -## 빠른 참조: 핵심 용어 +## 빠른 참조: 주요 용어 -DoubleZero가 처음이신가요? 필수 용어는 다음과 같습니다([전체 용어집](glossary.md) 참조): +DoubleZero가 처음이신가요? 다음은 필수 용어입니다 ([전체 용어집](glossary.md) 참조): | 용어 | 정의 | |------|------------| -| **DZD** | DoubleZero Device — DZ 에이전트를 실행하는 물리적 Arista 스위치 | -| **DZX** | DoubleZero Exchange — 기여자들이 서로 연결하는 도시 상호 연결 지점 | -| **CYOA** | Choose Your Own Adventure — 사용자 연결 방법 (GREOverDIA, GREOverFabric 등) | -| **DIA** | Direct Internet Access — 모든 DZD가 컨트롤러 및 텔레메트리를 위해 필요한 인터넷 연결, 엣지/하이브리드 장치의 사용자 연결을 위한 CYOA 유형으로도 일반적으로 사용 | -| **WAN 링크** | 자신의 DZD 간 링크 (동일 기여자) | -| **DZX 링크** | 다른 기여자의 DZD에 대한 링크 (상호 수락 필요) | -| **Config Agent** | 컨트롤러에 쿼리하고 DZD에 구성 적용 | -| **Telemetry Agent** | TWAMP 대기 시간/손실 메트릭스 수집, 온체인 레저에 제출 | -| **서비스 키** | CLI 작업을 위한 기여자 ID 키 | -| **메트릭스 발행자 키** | 온체인 텔레메트리 제출 서명을 위한 키 | +| **DZD** | DoubleZero Device - DZ 에이전트를 실행하는 물리적 Arista 스위치 | +| **DZX** | DoubleZero Exchange - 기여자들이 피어링하는 메트로 인터커넥트 포인트 | +| **CYOA** | Choose Your Own Adventure - 사용자 연결 방식 (GREOverDIA, GREOverFabric 등) | +| **DIA** | Direct Internet Access - 컨트롤러 및 텔레메트리를 위해 모든 DZD에 필요한 인터넷 연결, 엣지/하이브리드 디바이스에서 사용자 연결을 위한 CYOA 유형으로 일반적으로 사용됨 | +| **WAN Link** | 자체 DZD 간의 링크 (동일 기여자) | +| **DZX Link** | 다른 기여자의 DZD로의 링크 (상호 수락 필요) | +| **Config Agent** | 컨트롤러를 폴링하고 DZD에 설정을 적용 | +| **Telemetry Agent** | TWAMP 지연/손실 메트릭을 수집하고 온체인 원장에 제출 | +| **Service Key** | CLI 작업을 위한 기여자 신원 키 | +| **Metrics Publisher Key** | 온체인 텔레메트리 제출 서명을 위한 키 | +| **Rewards Manager Key** | 리워드를 수령할 지갑을 제어하는 키 | --- @@ -135,42 +142,44 @@ DoubleZero가 처음이신가요? 필수 용어는 다음과 같습니다([전 | 가이드 | 설명 | |-------|-------------| | [요구사항 및 아키텍처](contribute.md) | 하드웨어 사양, 네트워크 아키텍처, 대역폭 옵션 | -| [장치 프로비저닝](contribute-provisioning.md) | 단계별: 키 → 저장소 접근 → 장치 → 링크 → 에이전트 | -| [운영](contribute-operations.md) | 에이전트 업데이트, 링크 관리, 모니터링 | +| [디바이스 프로비저닝](contribute-provisioning.md) | 단계별: 키 → 리포지토리 접근 → 디바이스 → 링크 → 에이전트 | +| [리워드 관리](contribute-rewards.md) | 2Z 리워드를 수령할 지갑 설정 | +| [운영](contribute-operations.md) | 에이전트 업그레이드, 링크 관리, 모니터링 | +| [Geoprobe 배포](contribute-geolocation.md) | 지오로케이션을 위한 geoProbe 에이전트 배포 및 설정 | | [용어집](glossary.md) | 모든 DoubleZero 용어 정의 | --- -## 비네트워크 엔지니어를 위한 네트워킹 개념 +## 비네트워크 엔지니어를 위한 네트워크 기초 -네트워크 엔지니어링 경험이 없으시다면 이 문서에 사용된 개념에 대한 소개가 있습니다: +네트워크 엔지니어링 배경이 아닌 경우, 이 문서에서 사용되는 개념에 대한 입문 가이드입니다: ### IP 주소 지정 -- **IPv4 주소**: 네트워크의 장치에 대한 고유 식별자 (예: `192.168.1.1`) -- **CIDR 표기법** (`/29`, `/24`): 서브넷 크기를 나타냅니다. `/29` = 8개 주소, `/24` = 256개 주소 -- **공개 IP**: 인터넷에서 라우팅 가능; **사설 IP**: 내부 네트워크 전용 (10.x, 172.16-31.x, 192.168.x) +- **IPv4 주소**: 네트워크에서 디바이스의 고유 식별자 (예: `192.168.1.1`) +- **CIDR 표기법** (`/29`, `/24`): 서브넷 크기를 나타냄. `/29` = 8개 주소, `/24` = 256개 주소 +- **공인 IP**: 인터넷에서 라우팅 가능; **사설 IP**: 내부 네트워크 전용 (10.x, 172.16-31.x, 192.168.x) ### 네트워크 계층 -- **계층 1 (물리)**: 케이블, 광학, 파장 -- **계층 2 (데이터 링크)**: 스위치, VLAN, MAC 주소 -- **계층 3 (네트워크)**: 라우터, IP 주소, 라우팅 프로토콜 +- **레이어 1 (물리 계층)**: 케이블, 광학 장치, 파장 +- **레이어 2 (데이터 링크 계층)**: 스위치, VLAN, MAC 주소 +- **레이어 3 (네트워크 계층)**: 라우터, IP 주소, 라우팅 프로토콜 ### 일반 용어 -- **MTU**: 최대 전송 단위 — 최대 패킷 크기 (WAN 링크의 경우 일반적으로 9000바이트) -- **VLAN**: 가상 LAN — 공유 인프라에서 트래픽을 논리적으로 분리 -- **VRF**: 가상 라우팅 및 포워딩 — 동일한 장치에서 라우팅 테이블을 격리 -- **BGP**: 경계 게이트웨이 프로토콜 — 네트워크 간 경로 교환 -- **GRE**: 일반 라우팅 캡슐화 — 오버레이 네트워크를 위한 터널링 프로토콜 -- **TWAMP**: 양방향 능동 측정 프로토콜 — 장치 간 대기 시간/손실 측정 +- **MTU**: Maximum Transmission Unit - 최대 패킷 크기 (일반적으로 WAN 링크의 경우 9000바이트) +- **VLAN**: Virtual LAN - 공유 인프라에서 트래픽을 논리적으로 분리 +- **VRF**: Virtual Routing and Forwarding - 동일 디바이스에서 라우팅 테이블을 격리 +- **BGP**: Border Gateway Protocol - 네트워크 간 라우트 교환 +- **GRE**: Generic Routing Encapsulation - 오버레이 네트워크를 위한 터널링 프로토콜 +- **TWAMP**: Two-Way Active Measurement Protocol - 디바이스 간 지연/손실 측정 -### DoubleZero 전용 +### DoubleZero 관련 용어 -- **온체인**: DoubleZero에서 장치 등록, 링크 구성 및 텔레메트리는 DoubleZero 레저에 기록되어 네트워크 상태를 모든 참여자가 투명하고 검증 가능하게 합니다 -- **컨트롤러**: DoubleZero 레저의 온체인 상태에서 DZD 구성을 도출하는 서비스 +- **온체인**: DoubleZero에서 디바이스 등록, 링크 설정 및 텔레메트리는 DoubleZero 원장에 기록됩니다 — 네트워크 상태를 모든 참여자가 투명하고 검증 가능하게 합니다 +- **컨트롤러**: DoubleZero 원장의 온체인 상태로부터 DZD 설정을 도출하는 서비스 --- -준비가 되셨나요? [요구사항 및 아키텍처](contribute.md)부터 시작하세요. +시작할 준비가 되셨나요? [요구사항 및 아키텍처](contribute.md)부터 시작하세요. \ No newline at end of file diff --git a/docs/contribute-overview.pt.md b/docs/contribute-overview.pt.md index 1898b90..032d815 100644 --- a/docs/contribute-overview.pt.md +++ b/docs/contribute-overview.pt.md @@ -1,79 +1,85 @@ -# Documentação para Contribuidores -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Visão geral e checklist de integração para se tornar um contribuidor da rede DoubleZero. +--- +# Documentação do Contribuidor !!! info "Terminologia" Novo no DoubleZero? Consulte o [Glossário](glossary.md) para definições de termos-chave como [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) e [CYOA](glossary.md#cyoa-choose-your-own-adventure). -Bem-vindo à documentação para contribuidores do DoubleZero. Esta seção cobre tudo que você precisa para se tornar um contribuidor de rede. +Bem-vindo à documentação do contribuidor do DoubleZero. Esta seção cobre tudo o que você precisa para se tornar um contribuidor da rede. -!!! tip "Interessado em se tornar um contribuidor de rede?" - Revise a página de [Requisitos e Arquitetura](contribute.md) para entender o hardware, a largura de banda e a conectividade necessários para contribuir com a rede DoubleZero. +!!! tip "Interessado em se tornar um contribuidor da rede?" + Consulte a página [Requisitos e Arquitetura](contribute.md) para entender o hardware, a largura de banda e a conectividade necessários para contribuir com a rede DoubleZero. --- -## Lista de Verificação de Integração +## Checklist de Integração -Use esta lista de verificação para acompanhar seu progresso. **Todos os itens devem ser concluídos antes que sua contribuição esteja tecnicamente operacional.** +Use este checklist para acompanhar seu progresso. **Todos os itens devem ser concluídos antes que sua contribuição esteja tecnicamente operacional.** ### Fase 1: Pré-requisitos -- [ ] CLI do DoubleZero instalado em um servidor de gerenciamento +- [ ] DoubleZero CLI instalado em um servidor de gerenciamento - [ ] Hardware adquirido e atendendo aos [requisitos](contribute.md#hardware-requirements) -- [ ] Espaço em rack e energia do data center disponíveis (4U, 4KW recomendado) -- [ ] DZD instalado fisicamente com conectividade de gerenciamento -- [ ] Bloco IPv4 público alocado para o protocolo DZ (**consulte as [Regras de Prefixo DZ](#dz-prefix-rules)**) +- [ ] Espaço em rack e energia disponíveis no data center (veja [Rack e Energia](contribute.md#rack-power-requirements)) +- [ ] DZD fisicamente instalado com conectividade de gerenciamento +- [ ] Bloco de IPv4 público alocado para o protocolo DZ (**veja [Regras de Prefixo DZ](#regras-de-prefixo-dz)**) ### Fase 2: Configuração de Conta - [ ] Par de chaves de serviço gerado (`doublezero keygen`) -- [ ] Par de chaves do editor de métricas gerado -- [ ] Chave de serviço enviada ao DZF para autorização +- [ ] Par de chaves do publicador de métricas gerado +- [ ] Carteira do gerenciador de recompensas criada e financiada com ~0.01 SOL +- [ ] Chave de serviço, chave do gerenciador de recompensas e nome de usuário do GitHub enviados à DZF (apenas chaves públicas) - [ ] Conta de contribuidor criada onchain (verificar com `doublezero contributor list`) +- [ ] Chave do gerenciador de recompensas registrada onchain pela DZF - [ ] Acesso concedido ao repositório [malbeclabs/contributors](https://github.com/malbeclabs/contributors) +- [ ] Carteiras destinatárias e percentuais configurados (**veja [Gerenciamento de Recompensas](contribute-rewards.md)**) +- [ ] Cada carteira destinatária possui uma conta de token 2Z -### Fase 3: Provisionamento de Dispositivos -- [ ] Configuração base do dispositivo aplicada (do repositório de contribuidores) +### Fase 3: Provisionamento de Dispositivo +- [ ] Configuração base do dispositivo aplicada (do repositório contributors) - [ ] Dispositivo criado onchain (`doublezero device create`) - [ ] Interfaces do dispositivo registradas -- [ ] Interfaces loopback criadas (Loopback255 vpnv4, Loopback256 ipv4) -- [ ] Interfaces CYOA/DIA configuradas (se dispositivo de borda/híbrido) +- [ ] Interfaces de loopback criadas (Loopback255 vpnv4, Loopback256 ipv4) +- [ ] Interfaces CYOA/DIA configuradas (se dispositivo edge/híbrido) -### Fase 4: Estabelecimento de Link e Instalação de Agentes +### Fase 4: Estabelecimento de Links e Instalação de Agentes - [ ] Links WAN criados (se aplicável) - [ ] Link DZX criado (status: `requested`) - [ ] Link DZX aceito pelo contribuidor par - [ ] Config Agent instalado e em execução -- [ ] Config Agent recebendo configuração do controlador +- [ ] Config Agent recebendo configuração do controller - [ ] Telemetry Agent instalado e em execução -- [ ] Editor de métricas registrado onchain -- [ ] Envios de telemetria visíveis no ledger +- [ ] Publicador de métricas registrado onchain +- [ ] Submissões de telemetria visíveis no ledger -### Fase 5: Rodagem do Link -- [ ] Todos os links drenados durante um período de rodagem de 24 horas -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) mostra zero perdas e zero erros durante 24h -- [ ] Links sem drenagem após uma rodagem limpa +### Fase 5: Período de Teste dos Links +- [ ] Todos os links drenados para período de teste de 24 horas +- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) mostra zero perda e zero erros por 24h +- [ ] Links restaurados após teste limpo ### Fase 6: Verificação e Ativação - [ ] `doublezero device list` mostra seu dispositivo (com `max_users = 0`) - [ ] `doublezero link list` mostra seus links -- [ ] Os logs do Config Agent mostram extrações de configuração bem-sucedidas -- [ ] Os logs do Telemetry Agent mostram envios de métricas bem-sucedidos -- [ ] **Coordenar com DZ/Malbec Labs** para executar um teste de conectividade (conectar, receber rotas, rotear sobre DZ) -- [ ] Após o teste passar, definir `max_users` como 96 via `doublezero device update` +- [ ] Logs do Config Agent mostram pulls de configuração bem-sucedidos +- [ ] Logs do Telemetry Agent mostram submissões de métricas bem-sucedidas +- [ ] **Coordenar com DZ/Malbec Labs** para executar teste de conectividade (conectar, receber rotas, rotear pelo DZ) +- [ ] Após aprovação no teste, definir `max_users` para 96 via `doublezero device update` --- -## Obter Ajuda +## Obtendo Ajuda -Como parte da integração, o DZF irá adicioná-lo aos canais Slack de contribuidores: +Como parte da integração, a DZF adicionará você aos canais do Slack para contribuidores: -| Canal | Propósito | -|---------|---------| -| **#dz-contributor-announcements** | Comunicações oficiais do DZF e Malbec Labs — atualizações de CLI/agentes, mudanças importantes, anúncios de segurança. Monitore para atualizações críticas; faça perguntas nas threads. | -| **#dz-contributor-incidents** | Eventos não planejados que afetam o serviço. Os incidentes são postados automaticamente via API/formulário web com severidade e dispositivos/links afetados. A discussão e resolução de problemas ocorrem nas threads. | -| **#dz-contributor-maintenance** | Atividades de manutenção planejadas (atualizações, reparos). Agendadas via API/formulário web com horários de início/fim planejados. Discussão nas threads. | +| Canal | Finalidade | +|-------|------------| +| **#dz-contributor-announcements** | Comunicações oficiais da DZF e Malbec Labs — atualizações de CLI/agentes, mudanças incompatíveis, avisos de segurança. Monitore para atualizações críticas; faça perguntas em threads. | +| **#dz-contributor-incidents** | Eventos não planejados com impacto no serviço. Incidentes são publicados automaticamente via API/formulário web com severidade e dispositivos/links afetados. Discussão e troubleshooting acontecem em threads. | +| **#dz-contributor-maintenance** | Atividades de manutenção planejada (upgrades, reparos). Agendadas via API/formulário web com horários planejados de início/fim. Discussão em threads. | | **#dz-contributor-ops** | Discussão aberta para todos os contribuidores — perguntas operacionais, ajuda com CLI, compartilhamento de runbooks e playbooks. | -Você também receberá um **canal privado do DZ/Malbec Labs** para suporte direto da sua organização. +Você também receberá um **canal privado DZ/Malbec Labs** para suporte direto à sua organização. --- @@ -84,14 +90,14 @@ Você também receberá um **canal privado do DZ/Malbec Labs** para suporte dire **Como os prefixos DZ são usados:** - - **Primeiro IP**: Reservado para o seu dispositivo (atribuído à interface Loopback100) + - **Primeiro IP**: Reservado para seu dispositivo (atribuído à interface Loopback100) - **IPs restantes**: Alocados para tipos específicos de usuários que se conectam ao seu DZD: - Usuários `IBRLWithAllocatedIP` - Usuários `EdgeFiltering` - Publicadores multicast - - **Usuários IBRL**: NÃO consomem deste pool (usam seu próprio IP público) + - **Usuários IBRL**: NÃO consomem deste pool (eles usam seu próprio IP público) - **NÃO pode usar esses endereços para:** + **Você NÃO PODE usar esses endereços para:** - Seu próprio equipamento de rede - Links ponto a ponto em interfaces DIA @@ -101,9 +107,9 @@ Você também receberá um **canal privado do DZ/Malbec Labs** para suporte dire **Requisitos:** - Devem ser endereços IPv4 **globalmente roteáveis (públicos)** - - Intervalos de IP privados (10.x, 172.16-31.x, 192.168.x) são rejeitados pelo contrato inteligente - - **Tamanho mínimo: /29** (8 endereços), prefixos maiores são preferidos (por exemplo, /28, /27) - - Todo o bloco deve estar disponível — não pré-aloque nenhum endereço + - Faixas de IP privado (10.x, 172.16-31.x, 192.168.x) são rejeitadas pelo smart contract + - **Tamanho mínimo: /29** (8 endereços), prefixos maiores são preferíveis (ex.: /28, /27) + - O bloco inteiro deve estar disponível - não pré-aloque nenhum endereço Se você precisar de endereços para seu próprio equipamento (IPs de interface DIA, gerenciamento, etc.), use um **pool de endereços separado**. @@ -111,20 +117,21 @@ Você também receberá um **canal privado do DZ/Malbec Labs** para suporte dire ## Referência Rápida: Termos-Chave -Novo no DoubleZero? Aqui estão os termos essenciais (consulte o [Glossário completo](glossary.md)): +Novo no DoubleZero? Aqui estão os termos essenciais (veja o [Glossário completo](glossary.md)): | Termo | Definição | -|------|------------| -| **DZD** | Dispositivo DoubleZero — seu switch físico Arista que executa os agentes DZ | -| **DZX** | DoubleZero Exchange — ponto de interconexão metropolitana onde os contribuidores se conectam entre si | -| **CYOA** | Choose Your Own Adventure — método de conectividade de usuários (GREOverDIA, GREOverFabric, etc.) | -| **DIA** | Acesso Direto à Internet — conectividade à internet requerida por todos os DZDs para o controlador e a telemetria, comumente usado como tipo CYOA para conectividade de usuários em dispositivos de borda/híbridos | -| **Link WAN** | Link entre seus próprios DZDs (mesmo contribuidor) | -| **Link DZX** | Link para o DZD de outro contribuidor (requer aceitação mútua) | -| **Config Agent** | Consulta o controlador, aplica a configuração ao seu DZD | -| **Telemetry Agent** | Coleta métricas de latência/perda TWAMP, envia ao ledger onchain | -| **Chave de Serviço** | Sua chave de identidade de contribuidor para operações do CLI | -| **Chave do Editor de Métricas** | Chave para assinar envios de telemetria onchain | +|-------|-----------| +| **DZD** | DoubleZero Device - seu switch físico Arista executando agentes DZ | +| **DZX** | DoubleZero Exchange - ponto de interconexão metropolitana onde contribuidores fazem peering | +| **CYOA** | Choose Your Own Adventure - método de conectividade do usuário (GREOverDIA, GREOverFabric, etc.) | +| **DIA** | Direct Internet Access - conectividade com a internet exigida por todos os DZDs para controller e telemetria, comumente usado como tipo CYOA para conectividade de usuários em dispositivos edge/híbridos | +| **WAN Link** | Link entre seus próprios DZDs (mesmo contribuidor) | +| **DZX Link** | Link para o DZD de outro contribuidor (requer aceitação mútua) | +| **Config Agent** | Consulta o controller, aplica configuração ao seu DZD | +| **Telemetry Agent** | Coleta métricas de latência/perda TWAMP, submete ao ledger onchain | +| **Service Key** | Sua chave de identidade de contribuidor para operações via CLI | +| **Metrics Publisher Key** | Chave para assinar submissões de telemetria onchain | +| **Rewards Manager Key** | Chave que controla quais carteiras recebem suas recompensas | --- @@ -133,23 +140,25 @@ Novo no DoubleZero? Aqui estão os termos essenciais (consulte o [Glossário com ## Estrutura da Documentação | Guia | Descrição | -|-------|-------------| +|------|-----------| | [Requisitos e Arquitetura](contribute.md) | Especificações de hardware, arquitetura de rede, opções de largura de banda | -| [Provisionamento de Dispositivos](contribute-provisioning.md) | Passo a passo: chaves → acesso ao repositório → dispositivo → links → agentes | +| [Provisionamento de Dispositivo](contribute-provisioning.md) | Passo a passo: chaves → acesso ao repositório → dispositivo → links → agentes | +| [Gerenciamento de Recompensas](contribute-rewards.md) | Configurando as carteiras que recebem suas recompensas 2Z | | [Operações](contribute-operations.md) | Atualizações de agentes, gerenciamento de links, monitoramento | +| [Implantação do Geoprobe](contribute-geolocation.md) | Implantação e configuração de agentes geoProbe para geolocalização | | [Glossário](glossary.md) | Toda a terminologia do DoubleZero definida | --- -## Conceitos de Rede para Não-Engenheiros de Rede +## Conceitos Básicos de Rede para Não-Engenheiros de Rede -Se você não tem experiência em engenharia de rede, aqui está uma introdução aos conceitos usados nesta documentação: +Se você não tem formação em engenharia de redes, aqui está uma introdução aos conceitos usados nesta documentação: ### Endereçamento IP -- **Endereço IPv4**: Um identificador único para um dispositivo em uma rede (por exemplo, `192.168.1.1`) +- **Endereço IPv4**: Um identificador único para um dispositivo em uma rede (ex.: `192.168.1.1`) - **Notação CIDR** (`/29`, `/24`): Indica o tamanho da sub-rede. `/29` = 8 endereços, `/24` = 256 endereços -- **IP público**: Roteável na internet; **IP privado**: Somente redes internas (10.x, 172.16-31.x, 192.168.x) +- **IP Público**: Roteável na internet; **IP Privado**: Apenas redes internas (10.x, 172.16-31.x, 192.168.x) ### Camadas de Rede @@ -159,18 +168,18 @@ Se você não tem experiência em engenharia de rede, aqui está uma introduçã ### Termos Comuns -- **MTU**: Unidade Máxima de Transmissão — tamanho máximo de pacote (tipicamente 9000 bytes para links WAN) -- **VLAN**: LAN Virtual — separa logicamente o tráfego em infraestrutura compartilhada -- **VRF**: Virtual Routing and Forwarding — isola tabelas de roteamento no mesmo dispositivo -- **BGP**: Border Gateway Protocol — troca de rotas entre redes -- **GRE**: Generic Routing Encapsulation — protocolo de tunelamento para redes overlay -- **TWAMP**: Two-Way Active Measurement Protocol — mede latência/perda entre dispositivos +- **MTU**: Maximum Transmission Unit - maior tamanho de pacote (tipicamente 9000 bytes para links WAN) +- **VLAN**: Virtual LAN - separa logicamente o tráfego em infraestrutura compartilhada +- **VRF**: Virtual Routing and Forwarding - isola tabelas de roteamento no mesmo dispositivo +- **BGP**: Border Gateway Protocol - troca de rotas entre redes +- **GRE**: Generic Routing Encapsulation - protocolo de tunelamento para redes overlay +- **TWAMP**: Two-Way Active Measurement Protocol - mede latência/perda entre dispositivos ### Específico do DoubleZero -- **Onchain**: No DoubleZero, os registros de dispositivos, as configurações de links e a telemetria são registrados no ledger DoubleZero, tornando o estado da rede transparente e verificável por todos os participantes -- **Controlador**: Serviço que deriva a configuração do DZD a partir do estado onchain no ledger DoubleZero +- **Onchain**: No DoubleZero, registros de dispositivos, configurações de links e telemetria são registrados no ledger do DoubleZero — tornando o estado da rede transparente e verificável por todos os participantes +- **Controller**: Serviço que deriva a configuração do DZD a partir do estado onchain no ledger do DoubleZero --- -Pronto para começar? Comece com [Requisitos e Arquitetura](contribute.md). +Pronto para começar? Comece com [Requisitos e Arquitetura](contribute.md). \ No newline at end of file diff --git a/docs/contribute-overview.zh.md b/docs/contribute-overview.zh.md index 55647ac..42f8fba 100644 --- a/docs/contribute-overview.zh.md +++ b/docs/contribute-overview.zh.md @@ -1,130 +1,137 @@ -# 贡献者文档 -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: 成为 DoubleZero 网络贡献者的概述和入门清单。 +--- +# 贡献者文档 -!!! info "术语" - 初次使用DoubleZero？请参阅[词汇表](glossary.md)了解[DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange)和[CYOA](glossary.md#cyoa-choose-your-own-adventure)等关键术语的定义。 +!!! info "术语说明" + 初次接触 DoubleZero？请参阅[术语表](glossary.md)了解关键术语的定义，如 [DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange) 和 [CYOA](glossary.md#cyoa-choose-your-own-adventure)。 -欢迎阅读DoubleZero贡献者文档。本节涵盖成为网络贡献者所需的一切内容。 +欢迎阅读 DoubleZero 贡献者文档。本节涵盖了成为网络贡献者所需的全部内容。 !!! tip "有兴趣成为网络贡献者？" - 请查看[需求与架构](contribute.md)页面，了解为DoubleZero网络做贡献所需的硬件、带宽和连接要求。 + 请查看[要求与架构](contribute.md)页面，了解为 DoubleZero 网络做贡献所需的硬件、带宽和连接要求。 --- -## 入职核对清单 - -使用此核对清单跟踪您的进度。**在您的贡献在技术上正式运营之前，所有项目必须完成。** - -### 第一阶段：前提条件 -- [ ] 在管理服务器上安装DoubleZero CLI -- [ ] 硬件已采购并符合[要求](contribute.md#hardware-requirements) -- [ ] 数据中心机架空间和电源可用（推荐4U、4KW） -- [ ] DZD已物理安装并具有管理连接 -- [ ] 为DZ协议分配公共IPv4地址块（**参见[DZ前缀规则](#dz-prefix-rules)**） - -### 第二阶段：账户设置 -- [ ] 生成服务密钥对（`doublezero keygen`） -- [ ] 生成指标发布者密钥对 -- [ ] 服务密钥已提交给DZF进行授权 -- [ ] 链上创建贡献者账户（通过`doublezero contributor list`验证） -- [ ] 获得[malbeclabs/contributors](https://github.com/malbeclabs/contributors)仓库访问权限 - -### 第三阶段：设备配置 -- [ ] 已应用基础设备配置（来自contributors仓库） -- [ ] 链上创建设备（`doublezero device create`） -- [ ] 设备接口已注册 -- [ ] 环回接口已创建（Loopback255 vpnv4，Loopback256 ipv4） -- [ ] CYOA/DIA接口已配置（如果是边缘/混合设备） - -### 第四阶段：链路建立与代理安装 -- [ ] WAN链路已创建（如适用） -- [ ] DZX链路已创建（状态：`requested`） -- [ ] DZX链路已由对等贡献者接受 -- [ ] 配置代理已安装并运行 -- [ ] 配置代理正在从控制器接收配置 -- [ ] 遥测代理已安装并运行 +## 入门清单 + +使用此清单跟踪您的进度。**所有项目必须全部完成，您的贡献才能在技术上正式运行。** + +### 阶段 1：前提条件 +- [ ] 在管理服务器上安装 DoubleZero CLI +- [ ] 已采购硬件并满足[要求](contribute.md#hardware-requirements) +- [ ] 数据中心机架空间和电力已就绪（参见[机架与电力](contribute.md#rack-power-requirements)） +- [ ] DZD 已物理安装并具备管理连接 +- [ ] 已分配用于 DZ 协议的公共 IPv4 地址块（**参见 [DZ 前缀规则](#dz-prefix-rules)**） + +### 阶段 2：账户设置 +- [ ] 已生成服务密钥对（`doublezero keygen`） +- [ ] 已生成指标发布者密钥对 +- [ ] 已创建奖励管理器钱包并充入约 0.01 SOL +- [ ] 已向 DZF 提交服务密钥、奖励管理器密钥和 GitHub 用户名（仅公钥） +- [ ] 贡献者账户已在链上创建（通过 `doublezero contributor list` 验证） +- [ ] 奖励管理器密钥已由 DZF 在链上注册 +- [ ] 已获得 [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 仓库的访问权限 +- [ ] 已配置接收钱包和百分比（**参见[奖励管理](contribute-rewards.md)**） +- [ ] 每个接收钱包都有一个 2Z 代币账户 + +### 阶段 3：设备配置 +- [ ] 已应用基础设备配置（来自 contributors 仓库） +- [ ] 已在链上创建设备（`doublezero device create`） +- [ ] 已注册设备接口 +- [ ] 已创建环回接口（Loopback255 vpnv4、Loopback256 ipv4） +- [ ] 已配置 CYOA/DIA 接口（如果是边缘/混合设备） + +### 阶段 4：链路建立与 Agent 安装 +- [ ] 已创建 WAN 链路（如适用） +- [ ] 已创建 DZX 链路（状态：`requested`） +- [ ] DZX 链路已被对端贡献者接受 +- [ ] Config Agent 已安装并运行 +- [ ] Config Agent 正在从控制器接收配置 +- [ ] Telemetry Agent 已安装并运行 - [ ] 指标发布者已在链上注册 - [ ] 遥测提交在账本上可见 -### 第五阶段：链路磨合 -- [ ] 所有链路已清空进行24小时磨合期 -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz)显示24小时内零丢包和零错误 -- [ ] 清洁磨合后链路已取消清空 +### 阶段 5：链路老化测试 +- [ ] 所有链路已排空，进行 24 小时老化测试 +- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) 显示 24 小时内零丢包和零错误 +- [ ] 老化测试通过后取消链路排空 -### 第六阶段：验证与激活 -- [ ] `doublezero device list`显示您的设备（`max_users = 0`） -- [ ] `doublezero link list`显示您的链路 -- [ ] 配置代理日志显示成功的配置拉取 -- [ ] 遥测代理日志显示成功的指标提交 -- [ ] **与DZ/Malbec Labs协调**运行连接测试（连接、接收路由、通过DZ路由） -- [ ] 测试通过后，通过`doublezero device update`将`max_users`设置为96 +### 阶段 6：验证与激活 +- [ ] `doublezero device list` 显示您的设备（`max_users = 0`） +- [ ] `doublezero link list` 显示您的链路 +- [ ] Config Agent 日志显示配置拉取成功 +- [ ] Telemetry Agent 日志显示指标提交成功 +- [ ] **与 DZ/Malbec Labs 协调**运行连接测试（连接、接收路由、通过 DZ 路由） +- [ ] 测试通过后，通过 `doublezero device update` 将 `max_users` 设置为 96 --- ## 获取帮助 -作为入职的一部分，DZF将把您添加到贡献者Slack频道： +在入门过程中，DZF 会将您添加到贡献者 Slack 频道： | 频道 | 用途 | |---------|---------| -| **#dz-contributor-announcements** | DZF和Malbec Labs的官方通信——CLI/代理升级、重大更改、安全公告。监控关键更新；在线程中提问。 | -| **#dz-contributor-incidents** | 未计划的服务影响事件。事件通过API/Web表单自动发布，包含严重程度和受影响的设备/链路。讨论和故障排除在线程中进行。 | -| **#dz-contributor-maintenance** | 计划维护活动（升级、维修）。通过API/Web表单安排，包含计划开始/结束时间。讨论在线程中进行。 | -| **#dz-contributor-ops** | 所有贡献者的开放讨论——运营问题、CLI帮助、分享运行手册和操作手册。 | +| **#dz-contributor-announcements** | 来自 DZF 和 Malbec Labs 的官方通知 — CLI/Agent 升级、破坏性变更、安全公告。请关注关键更新；在帖子中提问。 | +| **#dz-contributor-incidents** | 非计划性服务影响事件。事件通过 API/Web 表单自动发布，包含严重程度和受影响的设备/链路。在帖子中进行讨论和故障排除。 | +| **#dz-contributor-maintenance** | 计划维护活动（升级、维修）。通过 API/Web 表单安排，包含计划开始/结束时间。在帖子中讨论。 | +| **#dz-contributor-ops** | 面向所有贡献者的开放讨论 — 运维问题、CLI 帮助、分享运维手册和操作指南。 | -您还将获得一个用于您组织直接支持的**私有DZ/Malbec Labs频道**。 +您还将获得一个**私有的 DZ/Malbec Labs 频道**，为您的组织提供直接支持。 --- -## DZ前缀规则 +## DZ 前缀规则 -!!! warning "重要：DZ前缀池使用" - 您提供的DZ前缀池由**DoubleZero协议管理，用于IP分配**。 +!!! warning "重要：DZ 前缀池使用规则" + 您提供的 DZ 前缀池**由 DoubleZero 协议管理，用于 IP 地址分配**。 - **DZ前缀的使用方式：** + **DZ 前缀的使用方式：** - - **第一个IP**：为您的设备保留（分配给Loopback100接口） - - **剩余IP**：分配给连接到您DZD的特定用户类型： - - `IBRLWithAllocatedIP`用户 - - `EdgeFiltering`用户 - - 多播发布者 - - **IBRL用户**：不消耗此池（他们使用自己的公共IP） + - **第一个 IP**：保留给您的设备（分配给 Loopback100 接口） + - **剩余 IP**：分配给连接到您 DZD 的特定用户类型： + - `IBRLWithAllocatedIP` 用户 + - `EdgeFiltering` 用户 + - 组播发布者 + - **IBRL 用户**：不从此池中消耗（他们使用自己的公共 IP） **您不能将这些地址用于：** - 您自己的网络设备 - - DIA接口上的点对点链路 + - DIA 接口上的点对点链路 - 管理接口 - - DZ协议之外的任何基础设施 + - DZ 协议之外的任何基础设施 **要求：** - - 必须是**全球可路由（公共）**的IPv4地址 - - 智能合约拒绝私有IP范围（10.x、172.16-31.x、192.168.x） - - **最小大小：/29**（8个地址），首选更大的前缀（如/28、/27） - - 整个地址块必须可用——不要预先分配任何地址 + - 必须是**全球可路由（公共）**的 IPv4 地址 + - 私有 IP 范围（10.x、172.16-31.x、192.168.x）会被智能合约拒绝 + - **最小大小：/29**（8 个地址），建议使用更大的前缀（例如 /28、/27） + - 整个地址块必须可用 - 请勿预先分配任何地址 - 如果您需要用于自己设备的地址（DIA接口IP、管理地址等），请使用**单独的地址池**。 + 如果您需要地址用于自己的设备（DIA 接口 IP、管理等），请使用**单独的地址池**。 --- ## 快速参考：关键术语 -初次使用DoubleZero？以下是基本术语（参见[完整词汇表](glossary.md)）： +初次接触 DoubleZero？以下是核心术语（参见[完整术语表](glossary.md)）： | 术语 | 定义 | |------|------------| -| **DZD** | DoubleZero设备——运行DZ代理的物理Arista交换机 | -| **DZX** | DoubleZero交换点——贡献者对等的城域互连点 | -| **CYOA** | 自选冒险——用户连接方法（GREOverDIA、GREOverFabric等） | -| **DIA** | 直接互联网访问——所有DZD用于控制器和遥测的互联网连接，通常用作边缘/混合设备上用户连接的CYOA类型 | -| **WAN链路** | 您自己的DZD之间的链路（同一贡献者） | -| **DZX链路** | 到另一贡献者DZD的链路（需要相互接受） | -| **配置代理** | 轮询控制器，将配置应用到您的DZD | -| **遥测代理** | 收集TWAMP延迟/丢包指标，提交到链上账本 | -| **服务密钥** | 您的贡献者身份密钥，用于CLI操作 | -| **指标发布者密钥** | 用于签署链上遥测提交的密钥 | +| **DZD** | DoubleZero Device - 运行 DZ Agent 的物理 Arista 交换机 | +| **DZX** | DoubleZero Exchange - 贡献者之间互联的城域交换点 | +| **CYOA** | Choose Your Own Adventure - 用户连接方式（GREOverDIA、GREOverFabric 等） | +| **DIA** | Direct Internet Access - 所有 DZD 所需的互联网连接，用于控制器和遥测；也常作为边缘/混合设备上用户连接的 CYOA 类型 | +| **WAN Link** | 您自己的 DZD 之间的链路（同一贡献者） | +| **DZX Link** | 连接到其他贡献者 DZD 的链路（需要双方接受） | +| **Config Agent** | 轮询控制器，将配置应用到您的 DZD | +| **Telemetry Agent** | 收集 TWAMP 延迟/丢包指标，提交到链上账本 | +| **Service Key** | 您的贡献者身份密钥，用于 CLI 操作 | +| **Metrics Publisher Key** | 用于在链上签署遥测提交的密钥 | +| **Rewards Manager Key** | 控制哪些钱包接收您奖励的密钥 | --- @@ -134,43 +141,45 @@ | 指南 | 描述 | |-------|-------------| -| [需求与架构](contribute.md) | 硬件规格、网络架构、带宽选项 | -| [设备配置](contribute-provisioning.md) | 分步操作：密钥→仓库访问→设备→链路→代理 | -| [运营](contribute-operations.md) | 代理升级、链路管理、监控 | -| [词汇表](glossary.md) | 所有DoubleZero术语定义 | +| [要求与架构](contribute.md) | 硬件规格、网络架构、带宽选项 | +| [设备配置](contribute-provisioning.md) | 分步指南：密钥 → 仓库访问 → 设备 → 链路 → Agent | +| [奖励管理](contribute-rewards.md) | 设置接收 2Z 奖励的钱包 | +| [运维操作](contribute-operations.md) | Agent 升级、链路管理、监控 | +| [Geoprobe 部署](contribute-geolocation.md) | 部署和配置 geoProbe Agent 以实现地理定位 | +| [术语表](glossary.md) | 所有 DoubleZero 术语定义 | --- -## 非网络工程师的网络基础知识 +## 面向非网络工程师的网络基础知识 -如果您不是网络工程师背景，以下是本文档中使用的概念入门： +如果您没有网络工程背景，以下是本文档中使用的概念入门： -### IP寻址 +### IP 地址 -- **IPv4地址**：网络上设备的唯一标识符（如`192.168.1.1`） -- **CIDR表示法**（`/29`、`/24`）：指示子网大小。`/29` = 8个地址，`/24` = 256个地址 -- **公共IP**：在互联网上可路由；**私有IP**：仅限内部网络（10.x、172.16-31.x、192.168.x） +- **IPv4 地址**：网络上设备的唯一标识符（例如 `192.168.1.1`） +- **CIDR 表示法**（`/29`、`/24`）：表示子网大小。`/29` = 8 个地址，`/24` = 256 个地址 +- **公共 IP**：可在互联网上路由；**私有 IP**：仅限内部网络（10.x、172.16-31.x、192.168.x） -### 网络层 +### 网络层次 -- **第1层（物理层）**：电缆、光纤、波长 -- **第2层（数据链路层）**：交换机、VLAN、MAC地址 -- **第3层（网络层）**：路由器、IP地址、路由协议 +- **第 1 层（物理层）**：线缆、光模块、波长 +- **第 2 层（数据链路层）**：交换机、VLAN、MAC 地址 +- **第 3 层（网络层）**：路由器、IP 地址、路由协议 ### 常用术语 -- **MTU**：最大传输单元——最大数据包大小（WAN链路通常为9000字节） -- **VLAN**：虚拟局域网——在共享基础设施上逻辑分隔流量 -- **VRF**：虚拟路由和转发——在同一设备上隔离路由表 -- **BGP**：边界网关协议——网络间路由交换 -- **GRE**：通用路由封装——覆盖网络的隧道协议 -- **TWAMP**：双向主动测量协议——测量设备之间的延迟/丢包 +- **MTU**：最大传输单元 - 最大数据包大小（WAN 链路通常为 9000 字节） +- **VLAN**：虚拟局域网 - 在共享基础设施上逻辑隔离流量 +- **VRF**：虚拟路由和转发 - 在同一设备上隔离路由表 +- **BGP**：边界网关协议 - 网络间路由交换 +- **GRE**：通用路由封装 - 用于覆盖网络的隧道协议 +- **TWAMP**：双向主动测量协议 - 测量设备间的延迟/丢包 -### DoubleZero特定 +### DoubleZero 特定术语 -- **链上**：在DoubleZero中，设备注册、链路配置和遥测记录在DoubleZero账本上——使所有参与者都能透明和可验证地了解网络状态 -- **控制器**：从DoubleZero账本上的链上状态派生DZD配置的服务 +- **链上**：在 DoubleZero 中，设备注册、链路配置和遥测数据都记录在 DoubleZero 账本上 — 使网络状态对所有参与者透明且可验证 +- **控制器**：从 DoubleZero 账本上的链上状态生成 DZD 配置的服务 --- -准备好开始了吗？从[需求与架构](contribute.md)开始。 +准备好开始了吗？请从[要求与架构](contribute.md)开始。 \ No newline at end of file diff --git a/docs/contribute-provisioning.es.md b/docs/contribute-provisioning.es.md index 547d4ef..77a33b2 100644 --- a/docs/contribute-provisioning.es.md +++ b/docs/contribute-provisioning.es.md @@ -1,62 +1,102 @@ -# Guía de Aprovisionamiento de Dispositivos -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Guía paso a paso para aprovisionar un Dispositivo DoubleZero (DZD) y registrar sus interfaces y roles en la cadena. +--- +# Guía de Aprovisionamiento de Dispositivos -Esta guía le lleva a través del aprovisionamiento de un Dispositivo DoubleZero (DZD) de principio a fin. Cada fase corresponde a la [Lista de Verificación de Incorporación](contribute-overview.md#onboarding-checklist). +Esta guía te acompaña a través del aprovisionamiento de un Dispositivo DoubleZero (DZD) de principio a fin. Cada fase corresponde a la [Lista de Verificación de Incorporación](contribute-overview.md#onboarding-checklist). --- ## Cómo Encaja Todo -Antes de entrar en los pasos, aquí está el panorama general de lo que está construyendo: +Esta guía te acompaña a través del registro de tu infraestructura en la cadena para que la red DoubleZero pueda enrutar tráfico a través de ella. Cuanto más completamente esté registrado tu dispositivo, más útil será para la red. Una representación completa en la cadena de tu dispositivo permite una mejor resolución de problemas, planificación de capacidad, y permite al controlador tomar decisiones informadas. Con el tiempo, el objetivo es que el controlador asuma más responsabilidad de configuración. + +### Conceptos clave + +**Interfaces** + +Las interfaces en un DZD vienen en diferentes formas: puertos Ethernet, canales de puertos (LAGs compuestos por múltiples puertos Ethernet) y loopbacks. Cada interfaz que desempeña un rol en la red necesita ser registrada en la cadena con las banderas apropiadas para que el protocolo sepa qué hace. + +Los puertos Ethernet y canales de puertos pueden cumplir los siguientes roles: + +| Bandera | Qué significa | +|---------|---------------| +| `--interface-dia dia` | Marca la interfaz como el enlace ascendente de acceso directo a internet | +| `--interface-cyoa ` | Declara cómo los usuarios establecen túneles GRE a través de esta interfaz (p. ej., por internet público, mediante un enlace de peering privado) | +| `--user-tunnel-endpoint true` | Esta interfaz lleva una IP pública en la que los usuarios terminan túneles GRE | + +Las interfaces usadas para enlaces WAN o DZX no llevan una bandera específica, se registran con su ancho de banda y luego se referencian cuando se crea el enlace. + +Las interfaces loopback sirven para varios propósitos: + +| Loopback | Qué significa | +|----------|---------------| +| **Loopback100 / 101** | Llevan IPs públicas en las que los usuarios terminan túneles GRE. Se registran con `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Se registra para que el controlador pueda asignar una IP usada para el ID de router BGP, peering VPN-IPv4 (unicast), identidad IS-IS y enrutamiento por segmentos | +| **Loopback256** (`ipv4`) | Se registra para que el controlador pueda asignar una IP usada para peering BGP IPv4 (multicast) y sesiones MSDP | + +**Enlaces** + +Los enlaces se registran por separado de las interfaces, y las interfaces deben existir en la cadena antes de que un enlace pueda referenciarlas. Cuando creas un enlace WAN o DZX, especificas una interfaz ya registrada como el punto final físico del enlace. No todas las interfaces están vinculadas a un enlace: las interfaces DIA, CYOA y loopback no están conectadas a un enlace. + +| Término | Qué significa | +|---------|---------------| +| **Enlace WAN** | Un enlace entre dos de tus propios DZDs | +| **Enlace DZX** | Un enlace entre tu DZD y el DZD de otro contribuidor | + +### Visión general de la arquitectura ```mermaid flowchart TB subgraph Onchain - SC[Ledger DoubleZero] + SC[Registro DoubleZero] end - subgraph Your Infrastructure + subgraph Tu Infraestructura MGMT[Servidor de Gestión
CLI DoubleZero] - DZD[Su DZD
Switch Arista] - DZD ---|Enlace WAN| DZD2[Su otro DZD] + subgraph DZD[Tu DZD] + CYOA["Interfaz DIA · CYOA
(enlace ascendente hacia usuarios)"] + WAN_INTF["Interfaz de enlace WAN"] + DZX_INTF["Interfaz de enlace DZX"] + LO100["Loopback100/101
(endpoint de túnel de usuario)"] + end + DZD2[Tu otro DZD] end - subgraph Other Contributor + subgraph Otro Contribuidor OtherDZD[Su DZD] end - subgraph Users - VAL[Validadores] - RPC[Nodos RPC] - end + USERS["Usuarios"] MGMT -.->|Registra dispositivos,
enlaces, interfaces| SC - DZD ---|Enlace DZX| OtherDZD - VAL ---|Conectar via Internet| DZD - RPC ---|Conectar via Internet| DZD + WAN_INTF ---|Enlace WAN| DZD2 + DZX_INTF ---|Enlace DZX| OtherDZD + USERS -.|Túnel GRE|.-> CYOA + CYOA ---|enruta hacia| LO100 ``` --- ## Fase 1: Requisitos Previos -Antes de poder aprovisionar un dispositivo, necesita el hardware físico configurado y algunas direcciones IP asignadas. +Antes de poder aprovisionar un dispositivo, necesitas tener el hardware físico configurado y algunas direcciones IP asignadas. -### Lo Que Necesita +### Lo Que Necesitas -| Requisito | Por Qué Es Necesario | -|-------------|-----------------| -| **Hardware DZD** | Switch Arista 7280CR3A (consulte [especificaciones de hardware](contribute.md#hardware-requirements)) | -| **Espacio en Rack** | 4U con flujo de aire adecuado | -| **Energía** | Alimentaciones redundantes, ~4KW recomendado | +| Requisito | Por Qué Se Necesita | +|-----------|---------------------| +| **Hardware DZD** | Switch Arista 7280CR3A (ver [especificaciones de hardware](contribute.md#hardware-requirements)) | +| **Espacio en Rack** | 1U por DZD, con flujo de aire adecuado. Ver [Rack y Alimentación](contribute.md#rack-power-requirements) | +| **Alimentación** | Dos alimentaciones independientes, cada una capaz de soportar toda la carga por sí sola. Ver [Rack y Alimentación](contribute.md#rack-power-requirements) | | **Acceso de Gestión** | Acceso SSH/consola para configurar el switch | -| **Conectividad a Internet** | Para publicación de métricas y para obtener configuración del controlador | +| **Conectividad a Internet** | Para publicar métricas y obtener configuración del controlador | | **Bloque IPv4 Público** | Mínimo /29 para el pool de prefijos DZ (ver abajo) | ### Instalar el CLI de DoubleZero -El CLI de DoubleZero (`doublezero`) se usa durante todo el aprovisionamiento para registrar dispositivos, crear enlaces y gestionar su contribución. Debe instalarse en un **servidor de gestión o VM**, no en el switch DZD en sí. El switch solo ejecuta el Agente de Configuración y el Agente de Telemetría (instalados en la [Fase 4](#phase-4-link-establishment-agent-installation)). +El CLI de DoubleZero (`doublezero`) se usa durante todo el aprovisionamiento para registrar dispositivos, crear enlaces y gestionar tu contribución. Debe instalarse en un **servidor de gestión o VM** — no en el switch DZD. El switch solo ejecuta el Agente de Configuración y el Agente de Telemetría (instalados en la [Fase 4](#fase-4-establecimiento-de-enlaces-e-instalación-de-agentes)). **Ubuntu / Debian:** ```bash @@ -70,75 +110,76 @@ curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.rpm.sh | sudo yum install doublezero ``` -Verificar que el daemon esté ejecutándose: +Verifica que el demonio esté ejecutándose: ```bash sudo systemctl status doublezerod ``` -### Comprendiendo Su Prefijo DZ +### Entendiendo Tu Prefijo DZ -Su prefijo DZ es un bloque de direcciones IP públicas que el protocolo DoubleZero gestiona para la asignación de IP. +Tu prefijo DZ es un bloque de direcciones IP públicas que el protocolo DoubleZero gestiona para la asignación de IPs. ```mermaid flowchart LR - subgraph "Su Bloque /29 (8 IPs)" - IP1["Primera IP
Reservada para
su dispositivo"] + subgraph "Tu Bloque /29 (8 IPs)" + IP1["Primera IP
Reservada para
tu dispositivo"] IP2["IP 2"] IP3["IP 3"] IP4["..."] IP8["IP 8"] end - IP1 -->|Asignada a| LO[Loopback100
en su DZD] + IP1 -->|Asignada a| LO[Loopback100
en tu DZD] IP2 -->|Asignada a| U1[Usuario 1] IP3 -->|Asignada a| U2[Usuario 2] ``` **Cómo se usan los prefijos DZ:** -- **Primera IP**: Reservada para su dispositivo (asignada a la interfaz Loopback100) -- **IPs restantes**: Asignadas a tipos específicos de usuarios que se conectan a su DZD: +- **Primera IP**: Reservada para tu dispositivo (asignada a la interfaz Loopback100) +- **IPs restantes**: Asignadas a tipos específicos de usuarios que se conectan a tu DZD: - Usuarios `IBRLWithAllocatedIP` - - Usuarios `EdgeFiltering` - - Publicadores multicast + - Usuarios `EdgeFiltering` (caso de uso futuro) - **Usuarios IBRL**: NO consumen de este pool (usan su propia IP pública) -!!! warning "Reglas de Prefijo DZ" - **NO PUEDE usar estas direcciones para:** +!!! warning "Reglas del Prefijo DZ" + **NO PUEDES usar estas direcciones para:** - - Su propio equipo de red + - Tu propio equipo de red - Enlaces punto a punto en interfaces DIA - Interfaces de gestión - Cualquier infraestructura fuera del protocolo DZ **Requisitos:** - - Deben ser direcciones IPv4 **globalmente enrutables (públicas)** + - Deben ser direcciones IPv4 **enrutables globalmente (públicas)** - Los rangos de IP privados (10.x, 172.16-31.x, 192.168.x) son rechazados por el contrato inteligente - - **Tamaño mínimo: /29** (8 direcciones), se prefieren prefijos más grandes (por ejemplo, /28, /27) - - Todo el bloque debe estar disponible — no preasigne ninguna dirección + - **Tamaño mínimo: /29** (8 direcciones), se prefieren prefijos más grandes (p. ej., /28, /27) + - El bloque completo debe estar disponible — no preasignes ninguna dirección - Si necesita direcciones para su propio equipo (IPs de interfaz DIA, gestión, etc.), use un **pool de direcciones separado**. + Si necesitas direcciones para tu propio equipo (IPs de interfaz DIA, gestión, etc.), usa un **pool de direcciones separado**. --- ## Fase 2: Configuración de Cuenta -En esta fase, crea las claves criptográficas que lo identifican a usted y a sus dispositivos en la red. +En esta fase, creas las claves criptográficas que te identifican a ti y a tus dispositivos en la red, e indicas dónde deben pagarse tus recompensas. + +Tres claves resultan de esta fase: una clave de servicio, una clave de publicador de métricas y una clave de gestor de recompensas. Envía las claves públicas de las tres a DZF juntas en el [Paso 2.4](#paso-24-enviar-claves-a-dzf). [Gestión de Recompensas](contribute-rewards.md) cubre completamente el lado de las recompensas. ### Dónde Ejecutar el CLI -!!! warning "NO instale el CLI en su switch" - El CLI de DoubleZero (`doublezero`) debe instalarse en un **servidor de gestión o VM**, no en su switch Arista. +!!! warning "NO instales el CLI en tu switch" + El CLI de DoubleZero (`doublezero`) debe instalarse en un **servidor de gestión o VM**, no en tu switch Arista. ```mermaid flowchart LR - subgraph "Servidor/VM de Gestión" + subgraph "Servidor de Gestión/VM" CLI[CLI DoubleZero] - KEYS[Sus Keypairs] + KEYS[Tus Pares de Claves] end - subgraph "Su Switch DZD" + subgraph "Tu Switch DZD" CA[Agente de Configuración] TA[Agente de Telemetría] end @@ -149,145 +190,206 @@ En esta fase, crea las claves criptográficas que lo identifican a usted y a sus ``` | Instalar en Servidor de Gestión | Instalar en Switch | - |-----------------------------|-------------------| + |---------------------------------|-------------------| | CLI `doublezero` | Agente de Configuración | - | Su keypair de servicio | Agente de Telemetría | - | Su keypair de editor de métricas | Keypair de editor de métricas (copia) | + | Tu par de claves de servicio | Agente de Telemetría | + | Tu par de claves de publicador de métricas | Par de claves de publicador de métricas (copia) | ### ¿Qué Son las Claves? -Piense en las claves como credenciales de inicio de sesión seguras: +Piensa en las claves como credenciales de inicio de sesión seguras: -- **Clave de Servicio**: Su identidad de contribuidor — usada para ejecutar comandos del CLI -- **Clave de Editor de Métricas**: La identidad de su dispositivo para enviar datos de telemetría +- **Clave de Servicio**: Tu identidad como contribuidor - usada para ejecutar comandos del CLI +- **Clave de Publicador de Métricas**: La identidad de tu dispositivo para enviar datos de telemetría +- **Clave de Gestor de Recompensas**: Controla qué billeteras reciben tus recompensas - ver [Gestión de Recompensas](contribute-rewards.md) -Ambas son keypairs criptográficos (una clave pública que comparte, una clave privada que mantiene en secreto). +Las tres son pares de claves criptográficas (una clave pública que compartes, una clave privada que mantienes en secreto). ```mermaid flowchart LR - subgraph "Sus Claves" + subgraph "Tus Claves" SK[Clave de Servicio
~/.config/solana/id.json] - MK[Clave de Editor de Métricas
~/.config/doublezero/metrics-publisher.json] + MK[Clave de Publicador de Métricas
~/.config/doublezero/metrics-publisher.json] + RK[Clave de Gestor de Recompensas
mantener fuera de línea] end SK -->|Usada para| CLI[Comandos CLI
doublezero device create
doublezero link create] - MK -->|Usada para| TEL[Agente de Telemetría
Envía métricas onchain] + MK -->|Usada para| TEL[Agente de Telemetría
Envía métricas en la cadena] + RK -->|Usada para| REW[Portal de Recompensas
Configura billeteras destinatarias] ``` -### Paso 2.1: Generar Su Clave de Servicio +!!! note "Mantén la clave de gestor de recompensas separada" + La clave de servicio y la clave de publicador de métricas residen en tu servidor de gestión y switch. La clave de gestor de recompensas controla hacia dónde va tu dinero, así que mantenla fuera de esas máquinas. Solo se necesita cuando cambias tus billeteras destinatarias. + +### Paso 2.1: Genera Tu Clave de Servicio -Esta es su identidad principal para interactuar con DoubleZero. +Esta es tu identidad principal para interactuar con DoubleZero. ```bash doublezero keygen ``` -Esto crea un keypair en la ubicación predeterminada. La salida muestra su **clave pública** — esto es lo que compartirá con DZF. +Esto crea un par de claves en la ubicación predeterminada. La salida muestra tu **clave pública** - esto es lo que compartirás con DZF. -### Paso 2.2: Generar Su Clave de Editor de Métricas +### Paso 2.2: Genera Tu Clave de Publicador de Métricas -Esta clave la usa el Agente de Telemetría para firmar envíos de métricas. +Esta clave es usada por el Agente de Telemetría para firmar los envíos de métricas. ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Paso 2.3: Enviar Claves a DZF +### Paso 2.3: Crea Tu Billetera de Gestor de Recompensas -Contacte a la Fundación DoubleZero o Malbec Labs y proporcione: +Esta es la tercera clave. Controla qué billeteras reciben tus recompensas, y nunca las retiene. -1. Su **clave pública de la clave de servicio** -2. Su **nombre de usuario de GitHub** (para acceso al repositorio) +Crea una billetera Solana que controles y con la que puedas firmar, luego fínanciala con aproximadamente 0.01 SOL para cubrir las tarifas de transacción. Una billetera de hardware es una buena opción. No reutilices tu clave de servicio. + +Solo necesitas la billetera en este punto. Configurarás las billeteras que realmente reciben tus recompensas en el [Paso 2.7](#paso-27-configura-tus-destinatarios-de-recompensas), después de que DZF haya registrado esta clave. + +### Paso 2.4: Enviar Claves a DZF + +Contacta a la Fundación DoubleZero o Malbec Labs y proporciona: + +1. Tu **clave pública de servicio** +2. Tu **clave pública de gestor de recompensas** (del Paso 2.3) +3. Tu **nombre de usuario de GitHub** (para acceso al repositorio) + +Envía las tres juntas. DZF registra la clave de servicio y la clave de gestor de recompensas en transacciones separadas en la cadena, así que enviarlas al mismo tiempo ahorra un viaje de ida y vuelta. + +!!! danger "Solo claves públicas" + Nunca envíes una clave privada o un archivo de par de claves a nadie, incluyendo DZF. DZF solo necesita tus claves públicas. Ellos: -- Crearán su **cuenta de contribuidor** onchain -- Otorgarán acceso al **repositorio de contribuidores** privado +- Crearán tu **cuenta de contribuidor** en la cadena +- Registrarán tu **clave de gestor de recompensas** contra tu clave de servicio +- Otorgarán acceso al **repositorio privado de contribuidores** -### Paso 2.4: Verificar Su Cuenta +### Paso 2.5: Verifica Tu Cuenta -Una vez confirmado, verifique que su cuenta de contribuidor existe: +Una vez confirmado, verifica que tu cuenta de contribuidor existe: ```bash doublezero contributor list ``` -Debería ver su código de contribuidor en la lista. +Deberías ver tu código de contribuidor en la lista. + +Verifica también que tu clave de gestor de recompensas fue registrada: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` -### Paso 2.5: Acceder al Repositorio de Contribuidores +La columna `manager` debería mostrar tu clave pública de gestor de recompensas. Si está vacía, pide a DZF que complete ese paso. + +### Paso 2.6: Accede al Repositorio de Contribuidores El repositorio [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contiene: - Configuraciones base de dispositivos - Perfiles TCAM -- Configuraciones ACL -- Instrucciones de configuración adicionales +- Configuraciones de ACL +- Instrucciones adicionales de configuración + +Sigue las instrucciones allí para la configuración específica del dispositivo. + +### Paso 2.7: Configura Tus Destinatarios de Recompensas + +Ahora indica qué billeteras reciben tus recompensas y en qué proporciones. Haz esto antes de que tu dispositivo comience a transportar tráfico. Las recompensas se acumulan desde el momento en que tus enlaces están activos, pero el protocolo no puede pagarlas hasta que hayas designado billeteras destinatarias. + +Inicia sesión en [doublezero.xyz/rewards](https://doublezero.xyz/rewards) con tu billetera de gestor de recompensas, selecciona tu clave de servicio, luego ingresa cada billetera destinataria y su porcentaje. Los porcentajes deben sumar 100. -Siga las instrucciones allí para la configuración específica del dispositivo. +!!! warning "Cada destinatario necesita una cuenta de token 2Z" + El protocolo envía 2Z con una transferencia de token simple y no crea la cuenta de token por ti. Una billetera destinataria sin cuenta de token 2Z causa que el pago de esa época falle. + +Consulta [Gestión de Recompensas](contribute-rewards.md) para el tutorial completo, incluyendo la alternativa por CLI, cómo verificar la cuenta de token y cómo verificar el resultado. --- -## Fase 3: Aprovisionamiento de Dispositivos +## Fase 3: Aprovisionamiento del Dispositivo + +Ahora registrarás tu dispositivo físico en la blockchain y configurarás sus interfaces. -Ahora registrará su dispositivo físico en la blockchain y configurará sus interfaces. +### Entendiendo los Tipos de Dispositivo -### Comprendiendo los Tipos de Dispositivos +**Edge** — acepta solo conexiones de usuarios ```mermaid -flowchart TB - subgraph "Dispositivo de Borde" - E[DZD de Borde] - EU[Los usuarios se conectan aquí] - EU --> E - E <-->|Enlace DZX| ED[Otro DZD] +flowchart LR + subgraph EDZD[DZD Edge] + E_CYOA["Interfaz DIA · CYOA"] + E_TUN["Loopback100/101 + (endpoint de túnel de usuario)"] + E_DZX["Interfaz de enlace DZX"] + E_CYOA --- E_TUN end + EU["Usuarios"] -.|Túnel GRE|.-> E_CYOA + E_DZX <-->|Enlace DZX| ED["DZD (contribuidor diferente)"] +``` + +**Transit** — mueve tráfico entre dispositivos, sin conexiones de usuarios - subgraph "Dispositivo de Tránsito" - T[DZD de Tránsito] - T <-->|Enlace WAN| T2[Otro DZD] - T <-->|Enlace DZX| TD[Otro DZD] +```mermaid +flowchart LR + subgraph TDZD[DZD Transit] + T_WAN["Interfaz de enlace WAN"] + T_DZX["Interfaz de enlace DZX"] end + T_WAN <-->|Enlace WAN| T2["DZD (mismo contribuidor)"] + T_DZX <-->|Enlace DZX| TD["DZD (contribuidor diferente)"] +``` - subgraph "Dispositivo Híbrido" - H[DZD Híbrido] - HU[Los usuarios se conectan aquí] - HU --> H - H <-->|Enlace WAN| H2[Otro DZD] - H <-->|Enlace DZX| HD[Otro DZD] +**Hybrid** — conexiones de usuarios y backbone, el más común + +```mermaid +flowchart LR + subgraph HDZD[DZD Hybrid] + H_CYOA["Interfaz DIA · CYOA"] + H_TUN["Loopback100/101 + (endpoint de túnel de usuario)"] + H_WAN["Interfaz de enlace WAN"] + H_DZX["Interfaz de enlace DZX"] + H_CYOA --- H_TUN end + HU["Usuarios"] -.|Túnel GRE|.-> H_CYOA + H_WAN <-->|Enlace WAN| H2["DZD (mismo contribuidor)"] + H_DZX <-->|Enlace DZX| HD["DZD (contribuidor diferente)"] ``` -| Tipo | Qué Hace | Cuándo Usar | -|------|--------------|-------------| -| **Borde** | Solo acepta conexiones de usuarios | Ubicación única, solo orientado al usuario | -| **Tránsito** | Mueve tráfico entre dispositivos | Conectividad de backbone, sin usuarios | -| **Híbrido** | Conexiones de usuarios Y backbone | Lo más común — hace todo | +| Tipo | Qué Hace | Cuándo Usarlo | +|------|----------|---------------| +| **Edge** | Acepta solo conexiones de usuarios | Ubicación única, solo orientado a usuarios | +| **Transit** | Mueve tráfico entre dispositivos | Conectividad backbone, sin usuarios | +| **Hybrid** | Conexiones de usuarios Y backbone | El más común - hace todo | -### Paso 3.1: Encontrar Su Ubicación e Exchange +### Paso 3.1: Encuentra Tu Ubicación e Intercambio -Antes de crear su dispositivo, busque los códigos de su ubicación de centro de datos y el exchange más cercano: +Antes de crear tu dispositivo, busca los códigos de la ubicación de tu centro de datos y el intercambio más cercano: ```bash # Listar ubicaciones disponibles (centros de datos) doublezero location list -# Listar exchanges disponibles (puntos de interconexión) +# Listar intercambios disponibles (puntos de interconexión) doublezero exchange list ``` -### Paso 3.2: Crear Su Dispositivo Onchain +### Paso 3.2: Crea Tu Dispositivo en la Cadena -Registre su dispositivo en la blockchain: +Registra tu dispositivo en la blockchain: ```bash doublezero device create \ - --code \ - --contributor \ + --code \ + --contributor \ --device-type hybrid \ - --location \ - --exchange \ - --public-ip \ - --dz-prefixes + --location \ + --exchange \ + --public-ip \ + --dz-prefixes ``` **Ejemplo:** @@ -309,7 +411,7 @@ doublezero device create \ Signature: 4vKz8H...truncated...7xPq2 ``` -Verifique que su dispositivo fue creado: +Verifica que tu dispositivo fue creado: ```bash doublezero device list | grep nyc-dz001 @@ -319,24 +421,24 @@ doublezero device list | grep nyc-dz001 | Parámetro | Qué Significa | |-----------|---------------| -| `--code` | Un nombre único para su dispositivo (por ejemplo, `nyc-dz001`) | -| `--contributor` | Su código de contribuidor (dado por DZF) | -| `--device-type` | `hybrid`, `transit` o `edge` | +| `--code` | Un nombre único para tu dispositivo (p. ej., `nyc-dz001`) | +| `--contributor` | Tu código de contribuidor (proporcionado por DZF) | +| `--device-type` | `hybrid`, `transit`, o `edge` | | `--location` | Código del centro de datos de `location list` | -| `--exchange` | Código del exchange más cercano de `exchange list` | -| `--public-ip` | La IP pública donde los usuarios se conectan a su dispositivo a través de internet | -| `--dz-prefixes` | Su bloque de IP asignado para usuarios | +| `--exchange` | Código del intercambio más cercano de `exchange list` | +| `--public-ip` | La IP pública donde los usuarios se conectan a tu dispositivo por internet | +| `--dz-prefixes` | Tu bloque de IP asignado para usuarios | -### Paso 3.3: Crear Interfaces Loopback Requeridas +### Paso 3.3: Crea las Interfaces Loopback Requeridas -Cada dispositivo necesita dos interfaces loopback para el enrutamiento interno: +Cada dispositivo necesita dos interfaces loopback para enrutamiento interno: ```bash # Loopback VPNv4 -doublezero device interface create Loopback255 --loopback-type vpnv4 +doublezero device interface create Loopback255 --loopback-type vpnv4 # Loopback IPv4 -doublezero device interface create Loopback256 --loopback-type ipv4 +doublezero device interface create Loopback256 --loopback-type ipv4 ``` **Salida esperada (para cada comando):** @@ -345,13 +447,20 @@ doublezero device interface create Loopback256 --loopback-type ipv Signature: 3mNx9K...truncated...8wRt5 ``` -### Paso 3.4: Crear Interfaces Físicas +### Paso 3.4: Crea Interfaces Físicas -Registre los puertos físicos que usará: +Registra las interfaces físicas que se usarán para enlaces WAN o DZX. Estas interfaces deben existir en la cadena antes de que puedas crear un enlace que las referencie. En este paso solo registras la interfaz y su ancho de banda, el enlace se crea en un paso posterior. ```bash -# Interfaz básica -doublezero device interface create Ethernet1/1 +doublezero device interface create \ + --bandwidth +``` + +**Ejemplo:** + +```bash +doublezero device interface create nyc-dz001 Ethernet1/1 \ + --bandwidth 10Gbps ``` **Salida esperada:** @@ -360,34 +469,36 @@ doublezero device interface create Ethernet1/1 Signature: 7pQw2R...truncated...4xKm9 ``` -### Paso 3.5: Crear Interfaz CYOA (para dispositivos de Borde/Híbridos) +Repite esto para cada interfaz que se usará como endpoint de un enlace WAN o DZX. Las interfaces CYOA y DIA se registran por separado en el siguiente paso. -Los DZDs híbridos y de borde necesitan **dos direcciones IP públicas** en las que los usuarios terminan sus túneles GRE. Los usuarios pueden conectarse por unicast, multicast, o ambos, y qué IP sirve para qué propósito rota por usuario. +### Paso 3.5: Crea la Interfaz CYOA (para dispositivos Edge/Hybrid) -Ambas IPs deben registrarse con `--user-tunnel-endpoint true`, ya sea en una interfaz física o en un loopback. Esto incluye la IP que proporcionó en el momento de la creación del dispositivo; esa IP aún necesita registrarse explícitamente aquí. +Los DZDs hybrid y edge necesitan **dos direcciones IP públicas** en las que los usuarios terminan sus túneles GRE. Los usuarios pueden conectarse por unicast, multicast, o ambos, y qué IP sirve para qué propósito rota por usuario. -Si tiene restricciones de IP, puede usar el primer `/32` de su prefijo DZ como una de las dos IPs. +Ambas IPs deben registrarse con `--user-tunnel-endpoint true`, ya sea en una interfaz física o un loopback. Esto incluye la IP que proporcionaste al crear el dispositivo, esa IP aún necesita registrarse explícitamente aquí. + +Si tienes restricciones de IP, puedes usar el primer `/32` de tu prefijo DZ como una de las dos IPs. #### CYOA y DIA -| Tipo | Flag | Propósito | -|------|------|-----------| +| Tipo | Bandera | Propósito | +|------|---------|-----------| | DIA | `--interface-dia dia` | Marca el puerto como acceso directo a internet | -| CYOA | `--interface-cyoa ` | Declara cómo los usuarios conectan túneles GRE a su dispositivo | +| CYOA | `--interface-cyoa ` | Declara cómo los usuarios conectan túneles GRE a tu dispositivo | -El flag CYOA siempre se establece en una **interfaz física** (puerto Ethernet o port channel). Nunca en un loopback. +La bandera CYOA siempre se establece en una **interfaz física** (puerto Ethernet o canal de puertos). Nunca en un loopback. -| Subtipo CYOA | Cuándo usar | -|-------------|-------------| -| `gre-over-dia` | Los usuarios se conectan a través de internet público. El más común. | -| `gre-over-private-peering` | Los usuarios se conectan mediante un cross-connect directo o circuito privado | -| `gre-over-public-peering` | Los usuarios hacen peering con usted en un Internet Exchange (IX) | -| `gre-over-fabric` | Los usuarios están co-ubicados y se conectan a través de un fabric local | -| `gre-over-cable` | Conexión de cable directo a un único usuario dedicado | +| Subtipo CYOA | Cuándo usarlo | +|--------------|---------------| +| `gre-over-dia` | Los usuarios se conectan por internet público. El más común. | +| `gre-over-private-peering` | Los usuarios se conectan mediante una conexión cruzada directa o circuito privado | +| `gre-over-public-peering` | Los usuarios hacen peering contigo en un Internet Exchange (IX) | +| `gre-over-fabric` | Los usuarios están co-ubicados y se conectan por un fabric local | +| `gre-over-cable` | Conexión directa por cable a un único usuario dedicado | #### Escenario A: Interfaz física única -Un uplink físico al ISP. Ethernet1/1 es la interfaz CYOA y DIA y lleva una de las dos IPs públicas. Loopback100 lleva la segunda IP pública. +Un único enlace ascendente físico al ISP. Ethernet1/1 es la interfaz CYOA y DIA y lleva una de las dos IPs públicas. Loopback100 lleva la segunda IP pública. ```mermaid flowchart LR @@ -396,9 +507,9 @@ flowchart LR subgraph DZD["DZD"] E1["Eth1/1 203.0.113.1/30 - CYOA · DIA · user tunnel endpoint"] + CYOA · DIA · endpoint de túnel de usuario"] LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n endpoint de túnel de usuario"] E1 --- LO end @@ -411,11 +522,11 @@ flowchart LR ``` | Interfaz | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| | Ethernet1/1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad del puerto | tasa comprometida | `bgp` o `static` | `true` | -| Loopback100 | — | — | su /32 público | `0bps` | — | — | `true` | +| Loopback100 | — | — | tu /32 público | `0bps` | — | — | `true` | -Ejemplo de comandos basado en el Escenario A: +Ejemplo de comandos a ejecutar basados en el Escenario A: ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -432,26 +543,26 @@ doublezero device interface create mydzd-nyc01 Loopback100 \ --user-tunnel-endpoint true ``` -#### Escenario B: Port channel (LAG) +#### Escenario B: Canal de puertos (LAG) -El DZD se conecta al dispositivo upstream mediante un port channel con una IP. El port channel lleva una IP pública y es el endpoint CYOA. Loopback100 lleva la segunda IP pública. +El DZD se conecta al dispositivo upstream mediante un canal de puertos con una IP. El canal de puertos lleva una IP pública y es el endpoint CYOA. Loopback100 lleva la segunda IP pública. ```mermaid flowchart LR USERS(["Usuarios Finales"]) - subgraph SW["Router/Switch Upstream"] + subgraph SW["Router / Switch Upstream"] SWPC(["bond0 203.0.113.2/30"]) end subgraph DZD["DZD"] - subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · user tunnel endpoint"] + subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · endpoint de túnel de usuario"] E1["Eth1/1"] E2["Eth2/1"] end LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n endpoint de túnel de usuario"] PC --- LO end @@ -461,11 +572,11 @@ flowchart LR ``` | Interfaz | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| | Port-Channel1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad combinada del LAG | tasa comprometida | `bgp` o `static` | `true` | -| Loopback100 | — | — | su /32 público | `0bps` | — | — | `true` | +| Loopback100 | — | — | tu /32 público | `0bps` | — | — | `true` | -Ejemplo de comandos basado en el Escenario B: +Ejemplo de comandos a ejecutar basados en el Escenario B: ```bash doublezero device interface create mydzd-fra01 Port-Channel1 \ --interface-cyoa gre-over-dia \ @@ -482,531 +593,7 @@ doublezero device interface create mydzd-fra01 Loopback100 \ --user-tunnel-endpoint true ``` -#### Escenario C: Doble uplink físico a routers separados - -Cada interfaz física se conecta a un router upstream diferente. Las dos IPs públicas se alojan en Loopback100 y Loopback101, ambas registradas como endpoints de túnel de usuario. - -```mermaid -flowchart LR - USERS(["Usuarios Finales"]) - - RA["Router A - 203.0.113.2/30"] - RB["Router B - 203.0.113.6/30"] - - subgraph DZD["DZD"] - E1["Eth1/1 - 203.0.113.1/30 - CYOA · DIA"] - E2["Eth2/1 - 203.0.113.5/30 - CYOA · DIA"] - LO0["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - LO1["Loopback101 - 198.51.100.2/32\n user tunnel endpoint"] - E1 --> LO0 - E2 --> LO1 - end - - RA -- "10GbE" --- E1 - RB -- "10GbE" --- E2 - USERS -. "Túneles GRE" .-> LO0 - USERS -. "Túneles GRE" .-> LO1 -``` - -| Interfaz | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad del puerto | tasa comprometida | `bgp` o `static` | — | -| Ethernet2/1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad del puerto | tasa comprometida | `bgp` o `static` | — | -| Loopback100 | — | — | su /32 público | `0bps` | — | — | `true` | -| Loopback101 | — | — | su /32 público | `0bps` | — | — | `true` | - -Ejemplo de comandos basado en el Escenario C: -```bash -doublezero device interface create mydzd-ams01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Ethernet2/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.5/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-ams01 Loopback101 \ - --ip-net 198.51.100.2/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -### Paso 3.6: Verificar Su Dispositivo - -```bash -doublezero device list -``` - -**Ejemplo de salida:** - -``` - account | code | contributor | location | exchange | device_type | public_ip | dz_prefixes | users | max_users | status | health | mgmt_vrf | owner - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -Su dispositivo debería aparecer con el estado `activated`. - ---- - -## Fase 4: Establecimiento de Enlace e Instalación de Agentes - -Los enlaces conectan su dispositivo al resto de la red DoubleZero. - -### Comprendiendo los Enlaces - -```mermaid -flowchart LR - subgraph "Su Red" - D1[Su DZD 1
NYC] - D2[Su DZD 2
LAX] - end - - subgraph "Otro Contribuidor" - O1[Su DZD
NYC] - end - - D1 ---|Enlace WAN
Mismo contribuidor| D2 - D1 ---|Enlace DZX
Diferentes contribuidores| O1 -``` - -| Tipo de Enlace | Conecta | Aceptación | -|-----------|----------|------------| -| **Enlace WAN** | Dos de SUS dispositivos | Automática (usted posee ambos) | -| **Enlace DZX** | Su dispositivo a OTRO contribuidor | Requiere su aceptación | - -### Paso 4.1: Crear Enlaces WAN (si tiene múltiples dispositivos) - -Los enlaces WAN conectan sus propios dispositivos: - -```bash -doublezero link create wan \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --side-z-interface \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 20 \ - --jitter-ms 1 -``` - -**Ejemplo:** - -```bash -doublezero link create wan \ - --code nyc-lax-wan01 \ - --contributor acme \ - --side-a nyc-dz001 \ - --side-a-interface Ethernet3/1 \ - --side-z lax-dz001 \ - --side-z-interface Ethernet3/1 \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 65 \ - --jitter-ms 1 -``` - -**Salida esperada:** - -``` -Signature: 5tNm7K...truncated...9pRw2 -``` - -### Paso 4.2: Crear Enlaces DZX - -Los enlaces DZX conectan su dispositivo directamente al DZD de otro contribuidor: - -```bash -doublezero link create dzx \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --bandwidth \ - --mtu \ - --delay-ms \ - --jitter-ms -``` - -**Salida esperada:** - -``` -Signature: 8mKp3W...truncated...2nRx7 -``` - -Después de crear un enlace DZX, el otro contribuidor debe aceptarlo: - -```bash -# El OTRO contribuidor ejecuta esto -doublezero link accept \ - --code \ - --side-z-interface -``` - -**Salida esperada (para el contribuidor que acepta):** - -``` -Signature: 6vQt9L...truncated...3wPm4 -``` - -### Paso 4.3: Verificar Enlaces - -```bash -doublezero link list -``` - -**Ejemplo de salida:** - -``` - account | code | contributor | side_a_name | side_a_iface_name | side_z_name | side_z_iface_name | link_type | bandwidth | mtu | delay_ms | jitter_ms | delay_override_ms | tunnel_id | tunnel_net | status | health | owner - 8vkYpXaBW8RuknJq... | nyc-dz001:lax-dz001 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -Los enlaces deben mostrar el estado `activated` una vez que ambos lados estén configurados. - ---- - -### Instalación de Agentes - -Dos agentes de software se ejecutan en su DZD: - -```mermaid -flowchart TB - subgraph "Su DZD" - CA[Agente de Configuración] - TA[Agente de Telemetría] - HW[Hardware/Software del Switch] - end - - CA -->|Obtiene configuración| CTRL[Servicio Controlador] - CA -->|Aplica configuración| HW - - HW -->|Métricas| TA - TA -->|Envía onchain| BC[Ledger DoubleZero] -``` - -| Agente | Qué Hace | -|-------|--------------| -| **Agente de Configuración** | Obtiene configuración del controlador, la aplica a su switch | -| **Agente de Telemetría** | Mide latencia/pérdida hacia otros dispositivos, reporta métricas onchain | - -### Paso 4.4: Instalar el Agente de Configuración - -#### Habilitar la API en su switch - -Agregar a la configuración EOS: - -``` -management api eos-sdk-rpc - transport grpc eapilocal - localhost loopback vrf default - service all - no disabled -``` - -!!! note "Nota sobre VRF" - Reemplace `default` con el nombre de su VRF de gestión si es diferente (por ejemplo, `management`). - -#### Descargar e instalar el agente - -```bash -# Entrar al bash en el switch -switch# bash -$ sudo bash -# cd /mnt/flash -# wget AGENT_DOWNLOAD_URL -# exit -$ exit - -# Instalar como extensión EOS -switch# copy flash:AGENT_FILENAME extension: -switch# extension AGENT_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Verificar la extensión - -```bash -switch# show extensions -``` - -El estado debe ser "A, I, B": - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -AGENT_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configurar e iniciar el agente - -Agregar a la configuración EOS: - -``` -daemon doublezero-agent - exec /usr/local/bin/doublezero-agent -pubkey - no shut -``` - -!!! note "Nota sobre VRF" - Si su VRF de gestión no es `default` (es decir, el espacio de nombres no es `ns-default`), prefije el comando exec con `exec /sbin/ip netns exec ns-`. Por ejemplo, si su VRF es `management`: - ``` - daemon doublezero-agent - exec /sbin/ip netns exec ns-management /usr/local/bin/doublezero-agent -pubkey - no shut - ``` - -Obtenga la pubkey de su dispositivo desde `doublezero device list` (la columna `account`). - -#### Verificar que está ejecutándose - -```bash -switch# show agent doublezero-agent logs -``` - -Debería ver "Starting doublezero-agent" y conexiones exitosas al controlador. - -### Paso 4.5: Instalar el Agente de Telemetría - -#### Copiar la clave de editor de métricas a su dispositivo - -```bash -scp ~/.config/doublezero/metrics-publisher.json :/mnt/flash/metrics-publisher-keypair.json -``` - -#### Registrar el editor de métricas onchain - -```bash -doublezero device update \ - --pubkey \ - --metrics-publisher -``` - -Obtenga la pubkey de su archivo metrics-publisher.json. - -#### Descargar e instalar el agente - -```bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget TELEMETRY_DOWNLOAD_URL -# exit -$ exit - -# Instalar como extensión EOS -switch# copy flash:TELEMETRY_FILENAME extension: -switch# extension TELEMETRY_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Verificar la extensión - -```bash -switch# show extensions -``` - -El estado debe ser "A, I, B": - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -TELEMETRY_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configurar e iniciar el agente - -Agregar a la configuración EOS: - -``` -daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut -``` - -!!! note "Nota sobre VRF" - Si su VRF de gestión no es `default` (es decir, el espacio de nombres no es `ns-default`), agregue `--management-namespace ns-` al comando exec. Por ejemplo, si su VRF es `management`: - ``` - daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --management-namespace ns-management --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut - ``` - -#### Verificar que está ejecutándose - -```bash -switch# show agent doublezero-telemetry logs -``` - -Debería ver "Starting telemetry collector" y "Starting submission loop". - ---- - -## Fase 5: Rodaje del Enlace - -!!! warning "Todos los nuevos enlaces deben rodar antes de transportar tráfico" - Los nuevos enlaces deben **estar drenados durante al menos 24 horas** antes de activarse para tráfico de producción. Este requisito de rodaje está definido en [RFC12: Aprovisionamiento de Red](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md), que especifica ~200,000 slots del Ledger DZ (~20 horas) de métricas limpias antes de que un enlace esté listo para servicio. - -Con los agentes instalados y funcionando, monitoree sus enlaces en [metrics.doublezero.xyz](https://metrics.doublezero.xyz) durante al menos 24 horas consecutivas: - -- Panel **"DoubleZero Device-Link Latencies"** — verifique **cero pérdida de paquetes** en el enlace a lo largo del tiempo -- Panel **"DoubleZero Network Metrics"** — verifique **cero errores** en sus enlaces - -Solo quite el drenado del enlace una vez que el período de rodaje muestre un enlace limpio con cero pérdidas y cero errores. - ---- - -## Fase 6: Verificación y Activación - -Repase esta lista de verificación para confirmar que todo está funcionando. - -!!! warning "Su dispositivo comienza bloqueado (`max_users = 0`)" - Cuando se crea un dispositivo, `max_users` se establece en **0** por defecto. Esto significa que ningún usuario puede conectarse a él todavía. Esto es intencional: debe verificar que todo funciona antes de aceptar tráfico de usuarios. - - **Antes de establecer `max_users` por encima de 0, debe:** - - 1. Confirmar que todos los enlaces han completado su **rodaje de 24 horas** con cero pérdidas/errores en [metrics.doublezero.xyz](https://metrics.doublezero.xyz) - 2. **Coordinar con DZ/Malbec Labs** para ejecutar una prueba de conectividad: - - ¿Puede un usuario de prueba conectarse a su dispositivo? - - ¿El usuario recibe rutas sobre la red DZ? - - ¿Puede el usuario enrutar tráfico sobre la red DZ de extremo a extremo? - 3. Solo después de que DZ/ML confirme que las pruebas pasen, establezca max_users en 96: - - ```bash - doublezero device update --pubkey --max-users 96 - ``` - -### Verificaciones del Dispositivo - -```bash -# Su dispositivo debería aparecer con el estado "activated" -doublezero device list | grep -``` - -**Salida esperada:** - -``` - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -```bash -# Sus interfaces deberían estar listadas -doublezero device interface list | grep -``` - -**Salida esperada:** - -``` - nyc-dz001 | Loopback255 | loopback | vpnv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.91/32 | 56 | false | activated - nyc-dz001 | Loopback256 | loopback | ipv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.100/32 | 0 | false | activated - nyc-dz001 | Ethernet1/1 | physical | none | none | none | 0 | 0 | 1500 | static | 0 | | 0 | false | activated -``` - -### Verificaciones de Enlace - -```bash -# Los enlaces deben mostrar el estado "activated" -doublezero link list | grep -``` - -**Salida esperada:** - -``` - 8vkYpXaBW8RuknJq... | nyc-lax-wan01 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -### Verificaciones de Agentes - -En el switch: - -```bash -# El agente de configuración debe mostrar obtenciones de configuración exitosas -switch# show agent doublezero-agent logs | tail -20 - -# El agente de telemetría debe mostrar envíos exitosos -switch# show agent doublezero-telemetry logs | tail -20 -``` - -### Diagrama de Verificación Final - -```mermaid -flowchart TB - subgraph "Lista de Verificación" - D[Estado del Dispositivo: activated?] - I[Interfaces: registradas?] - L[Enlaces: activated?] - CA[Agente de Configuración: obteniendo configuración?] - TA[Agente de Telemetría: enviando métricas?] - end - - D --> PASS - I --> PASS - L --> PASS - CA --> PASS - TA --> PASS - - PASS[Todas las Verificaciones Pasan] --> NOTIFY[Notificar a DZF/Malbec Labs
¡Está técnicamente listo!] -``` - ---- - -## Solución de Problemas - -### La creación del dispositivo falla - -- Verifique que su clave de servicio esté autorizada (`doublezero contributor list`) -- Compruebe que los códigos de ubicación y exchange son válidos -- Asegúrese de que el prefijo DZ sea un rango de IP pública válido - -### Enlace atascado en estado "requested" - -- Los enlaces DZX requieren aceptación por parte del otro contribuidor -- Contáctelos para ejecutar `doublezero link accept` - -### El Agente de Configuración no se conecta - -- Verifique que la red de gestión tiene acceso a internet -- Compruebe que la configuración VRF coincide con su configuración -- Asegúrese de que la pubkey del dispositivo es correcta - -### El Agente de Telemetría no envía - -- Verifique que la clave de editor de métricas esté registrada onchain -- Compruebe que el archivo keypair existe en el switch -- Asegúrese de que la pubkey de la cuenta del dispositivo es correcta - ---- -## Próximos Pasos +#### Escenario C: Enlaces ascendentes físicos duales a routers separados -- Revise la [Guía de Operaciones](contribute-operations.md) para actualizaciones de agentes y gestión de enlaces -- Consulte el [Glosario](glossary.md) para definiciones de términos -- Contacte a DZF/Malbec Labs si encuentra problemas +Cada \ No newline at end of file diff --git a/docs/contribute-provisioning.fr.md b/docs/contribute-provisioning.fr.md index b459c25..24ecafe 100644 --- a/docs/contribute-provisioning.fr.md +++ b/docs/contribute-provisioning.fr.md @@ -1,62 +1,102 @@ -# Guide de Provisionnement des Dispositifs -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Guide étape par étape pour provisionner un DoubleZero Device (DZD) et enregistrer ses interfaces et rôles on-chain. +--- +# Guide de provisionnement d'un appareil -Ce guide vous accompagne dans le provisionnement d'un DoubleZero Device (DZD) du début à la fin. Chaque phase correspond à la [Liste de Contrôle d'Intégration](contribute-overview.md#onboarding-checklist). +Ce guide vous accompagne dans le provisionnement d'un DoubleZero Device (DZD) du début à la fin. Chaque phase correspond à la [Liste de contrôle d'intégration](contribute-overview.md#onboarding-checklist). --- -## Vue d'Ensemble +## Comment tout s'articule + +Ce guide vous accompagne dans l'enregistrement de votre infrastructure on-chain afin que le réseau DoubleZero puisse acheminer le trafic à travers celle-ci. Plus votre appareil est complètement enregistré, plus il est utile au réseau. Une représentation on-chain complète de votre appareil permet un meilleur dépannage, une meilleure planification de la capacité, et permet au contrôleur de prendre des décisions éclairées. À terme, l'objectif est que le contrôleur prenne en charge une part croissante de la responsabilité de configuration. + +### Concepts clés + +**Interfaces** + +Les interfaces d'un DZD se présentent sous différentes formes : ports Ethernet, port channels (LAGs composés de plusieurs ports Ethernet) et loopbacks. Chaque interface qui joue un rôle dans le réseau doit être enregistrée on-chain avec les indicateurs appropriés afin que le protocole sache à quoi elle sert. + +Les ports Ethernet et les port channels peuvent remplir les rôles suivants : + +| Indicateur | Signification | +|------|---------------| +| `--interface-dia dia` | Marque l'interface comme liaison montante d'accès internet direct | +| `--interface-cyoa ` | Déclare comment les utilisateurs établissent des tunnels GRE via cette interface (ex. via l'internet public, via un lien de peering privé) | +| `--user-tunnel-endpoint true` | Cette interface porte une IP publique sur laquelle les utilisateurs terminent les tunnels GRE | + +Les interfaces utilisées pour les liens WAN ou DZX ne portent pas d'indicateur spécifique ; elles sont enregistrées avec leur bande passante puis référencées lors de la création du lien. + +Les interfaces loopback servent à plusieurs fins : + +| Loopback | Signification | +|----------|---------------| +| **Loopback100 / 101** | Portent des IP publiques sur lesquelles les utilisateurs terminent les tunnels GRE. Enregistrées avec `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Enregistrée pour que le contrôleur puisse assigner une IP utilisée pour l'identifiant de routeur BGP, le peering VPN-IPv4 (unicast), l'identité IS-IS et le segment routing | +| **Loopback256** (`ipv4`) | Enregistrée pour que le contrôleur puisse assigner une IP utilisée pour le peering BGP IPv4 (multicast) et les sessions MSDP | -Avant de plonger dans les étapes, voici la vue d'ensemble de ce que vous construisez : +**Liens** + +Les liens sont enregistrés séparément des interfaces, et les interfaces doivent exister on-chain avant qu'un lien puisse les référencer. Lorsque vous créez un lien WAN ou DZX, vous spécifiez une interface déjà enregistrée comme point de terminaison physique du lien. Toutes les interfaces ne sont pas liées à un lien : les interfaces DIA, CYOA et loopback ne sont pas connectées à un lien. + +| Terme | Signification | +|------|---------------| +| **Lien WAN** | Un lien entre deux de vos propres DZD | +| **Lien DZX** | Un lien entre votre DZD et le DZD d'un autre contributeur | + +### Vue d'ensemble de l'architecture ```mermaid flowchart TB subgraph Onchain - SC[Registre DoubleZero] + SC[DoubleZero Ledger] end - subgraph Votre Infrastructure - MGMT[Serveur de Gestion
CLI DoubleZero] - DZD[Votre DZD
Commutateur Arista] - DZD ---|Lien WAN| DZD2[Votre autre DZD] + subgraph Your Infrastructure + MGMT[Serveur de gestion
DoubleZero CLI] + subgraph DZD[Votre DZD] + CYOA["Interface DIA · CYOA
(liaison montante utilisateur)"] + WAN_INTF["Interface lien WAN"] + DZX_INTF["Interface lien DZX"] + LO100["Loopback100/101
(point de terminaison tunnel utilisateur)"] + end + DZD2[Votre autre DZD] end - subgraph Autre Contributeur + subgraph Other Contributor OtherDZD[Leur DZD] end - subgraph Utilisateurs - VAL[Validateurs] - RPC[Nœuds RPC] - end + USERS["Utilisateurs"] - MGMT -.->|Enregistre dispositifs,
liens, interfaces| SC - DZD ---|Lien DZX| OtherDZD - VAL ---|Connexion via Internet| DZD - RPC ---|Connexion via Internet| DZD + MGMT -.->|Enregistre appareils,
liens, interfaces| SC + WAN_INTF ---|Lien WAN| DZD2 + DZX_INTF ---|Lien DZX| OtherDZD + USERS -.|Tunnel GRE|.-> CYOA + CYOA ---|route vers| LO100 ``` --- ## Phase 1 : Prérequis -Avant de pouvoir provisionner un dispositif, vous avez besoin du matériel physique configuré et de quelques adresses IP allouées. +Avant de pouvoir provisionner un appareil, vous devez avoir le matériel physique installé et certaines adresses IP allouées. -### Ce Dont Vous Avez Besoin +### Ce dont vous avez besoin -| Exigence | Pourquoi C'est Nécessaire | -|----------|--------------------------| -| **Matériel DZD** | Commutateur Arista 7280CR3A (voir [spécifications matérielles](contribute.md#hardware-requirements)) | -| **Espace Baie** | 4U avec une ventilation appropriée | -| **Alimentation** | Alimentations redondantes, ~4KW recommandé | -| **Accès Gestion** | Accès SSH/console pour configurer le commutateur | -| **Connectivité Internet** | Pour la publication de métriques et pour récupérer la configuration depuis le contrôleur | -| **Bloc IPv4 Public** | Minimum /29 pour le pool de préfixes DZ (voir ci-dessous) | +| Exigence | Pourquoi c'est nécessaire | +|-------------|-----------------| +| **Matériel DZD** | Switch Arista 7280CR3A (voir les [spécifications matérielles](contribute.md#hardware-requirements)) | +| **Espace rack** | 1U par DZD, avec un flux d'air adéquat. Voir [Rack et alimentation](contribute.md#rack-power-requirements) | +| **Alimentation** | Deux alimentations indépendantes, chacune capable de supporter la charge totale seule. Voir [Rack et alimentation](contribute.md#rack-power-requirements) | +| **Accès de gestion** | Accès SSH/console pour configurer le switch | +| **Connectivité internet** | Pour la publication des métriques et la récupération de la configuration depuis le contrôleur | +| **Bloc IPv4 public** | Minimum /29 pour le pool de préfixes DZ (voir ci-dessous) | -### Installer la CLI DoubleZero +### Installer le CLI DoubleZero -La CLI DoubleZero (`doublezero`) est utilisée tout au long du provisionnement pour enregistrer les dispositifs, créer des liens et gérer votre contribution. Elle doit être installée sur un **serveur de gestion ou une VM** — pas sur le commutateur DZD lui-même. Le commutateur n'exécute que l'Agent de Configuration et l'Agent de Télémétrie (installés dans la [Phase 4](#phase-4-etablissement-des-liens-et-installation-des-agents)). +Le CLI DoubleZero (`doublezero`) est utilisé tout au long du provisionnement pour enregistrer les appareils, créer des liens et gérer votre contribution. Il doit être installé sur un **serveur de gestion ou une VM** — pas sur le switch DZD lui-même. Le switch exécute uniquement le Config Agent et le Telemetry Agent (installés en [Phase 4](#phase-4-etablissement-des-liens-installation-des-agents)). **Ubuntu / Debian :** ```bash @@ -75,106 +115,113 @@ Vérifiez que le démon est en cours d'exécution : sudo systemctl status doublezerod ``` -### Comprendre Votre Préfixe DZ +### Comprendre votre préfixe DZ -Votre préfixe DZ est un bloc d'adresses IP publiques que le protocole DoubleZero gère pour l'allocation IP. +Votre préfixe DZ est un bloc d'adresses IP publiques que le protocole DoubleZero gère pour l'allocation d'IP. ```mermaid flowchart LR - subgraph "Votre Bloc /29 (8 IPs)" - IP1["Première IP
Réservée pour
votre dispositif"] + subgraph "Votre bloc /29 (8 IPs)" + IP1["Première IP
Réservée pour
votre appareil"] IP2["IP 2"] IP3["IP 3"] IP4["..."] IP8["IP 8"] end - IP1 -->|Attribuée à| LO[Loopback100
sur votre DZD] + IP1 -->|Assignée à| LO[Loopback100
sur votre DZD] IP2 -->|Allouée à| U1[Utilisateur 1] IP3 -->|Allouée à| U2[Utilisateur 2] ``` **Comment les préfixes DZ sont utilisés :** -- **Première IP** : Réservée pour votre dispositif (attribuée à l'interface Loopback100) -- **IPs restantes** : Allouées à des types d'utilisateurs spécifiques se connectant à votre DZD : +- **Première IP** : Réservée pour votre appareil (assignée à l'interface Loopback100) +- **IP restantes** : Allouées à des types d'utilisateurs spécifiques se connectant à votre DZD : - Utilisateurs `IBRLWithAllocatedIP` - - Utilisateurs `EdgeFiltering` - - Éditeurs multicast -- **Utilisateurs IBRL** : N'utilisent PAS ce pool (ils utilisent leur propre IP publique) + - Utilisateurs `EdgeFiltering` (cas d'utilisation futur) +- **Utilisateurs IBRL** : Ne consomment PAS de ce pool (ils utilisent leur propre IP publique) -!!! warning "Règles du Préfixe DZ" +!!! warning "Règles des préfixes DZ" **Vous NE POUVEZ PAS utiliser ces adresses pour :** - - Votre propre matériel réseau - - Les liens point à point sur les interfaces DIA + - Votre propre équipement réseau + - Les liens point-à-point sur les interfaces DIA - Les interfaces de gestion - Toute infrastructure en dehors du protocole DZ **Exigences :** - - Doivent être des adresses IPv4 **globalement routables (publiques)** - - Les plages IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le contrat intelligent - - **Taille minimale : /29** (8 adresses), les préfixes plus grands sont préférés (par exemple, /28, /27) + - Doivent être des adresses IPv4 **routables globalement (publiques)** + - Les plages IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le smart contract + - **Taille minimale : /29** (8 adresses), les préfixes plus grands sont préférés (ex. /28, /27) - Le bloc entier doit être disponible — ne pré-allouez aucune adresse - Si vous avez besoin d'adresses pour votre propre équipement (IPs d'interface DIA, gestion, etc.), utilisez un **pool d'adresses séparé**. + Si vous avez besoin d'adresses pour votre propre équipement (IP d'interface DIA, gestion, etc.), utilisez un **pool d'adresses séparé**. --- -## Phase 2 : Configuration du Compte +## Phase 2 : Configuration du compte -Dans cette phase, vous créez les clés cryptographiques qui vous identifient, vous et vos dispositifs, sur le réseau. +Dans cette phase, vous créez les clés cryptographiques qui vous identifient, vous et vos appareils, sur le réseau, et vous indiquez où vos récompenses doivent être versées. -### Où Exécuter la CLI +Trois clés résultent de cette phase : une clé de service, une clé de publication de métriques et une clé de gestionnaire de récompenses. Soumettez les clés publiques des trois à la DZF ensemble à l'[Étape 2.4](#etape-24-soumettre-les-cles-a-la-dzf). [Gestion des récompenses](contribute-rewards.md) couvre le volet récompenses dans son intégralité. -!!! warning "N'installez PAS la CLI sur votre commutateur" - La CLI DoubleZero (`doublezero`) doit être installée sur un **serveur de gestion ou une VM**, pas sur votre commutateur Arista. +### Où exécuter le CLI + +!!! warning "N'installez PAS le CLI sur votre switch" + Le CLI DoubleZero (`doublezero`) doit être installé sur un **serveur de gestion ou une VM**, pas sur votre switch Arista. ```mermaid flowchart LR - subgraph "Serveur/VM de Gestion" - CLI[CLI DoubleZero] - KEYS[Vos Paires de Clés] + subgraph "Serveur de gestion/VM" + CLI[DoubleZero CLI] + KEYS[Vos paires de clés] end - subgraph "Votre Commutateur DZD" - CA[Agent de Configuration] - TA[Agent de Télémétrie] + subgraph "Votre switch DZD" + CA[Config Agent] + TA[Telemetry Agent] end - CLI -->|Crée dispositifs, liens| BC[Blockchain] + CLI -->|Crée appareils, liens| BC[Blockchain] CA -->|Récupère la config| CTRL[Contrôleur] TA -->|Soumet les métriques| BC ``` - | Installer sur le Serveur de Gestion | Installer sur le Commutateur | - |------------------------------------|------------------------------| - | CLI `doublezero` | Agent de Configuration | - | Votre clé de service | Agent de Télémétrie | - | Votre clé de publication de métriques | Clé de publication de métriques (copie) | + | Installer sur le serveur de gestion | Installer sur le switch | + |-----------------------------|-------------------| + | CLI `doublezero` | Config Agent | + | Votre paire de clés de service | Telemetry Agent | + | Votre paire de clés de publication de métriques | Paire de clés de publication de métriques (copie) | -### Qu'est-ce que les Clés ? +### Que sont les clés ? Pensez aux clés comme des identifiants de connexion sécurisés : -- **Clé de Service** : Votre identité de contributeur — utilisée pour exécuter les commandes CLI -- **Clé de Publication de Métriques** : L'identité de votre dispositif pour soumettre les données de télémétrie +- **Clé de service** : Votre identité de contributeur — utilisée pour exécuter les commandes CLI +- **Clé de publication de métriques** : L'identité de votre appareil pour soumettre les données de télémétrie +- **Clé de gestionnaire de récompenses** : Contrôle quels portefeuilles reçoivent vos récompenses — voir [Gestion des récompenses](contribute-rewards.md) -Les deux sont des paires de clés cryptographiques (une clé publique que vous partagez, une clé privée que vous gardez secrète). +Les trois sont des paires de clés cryptographiques (une clé publique que vous partagez, une clé privée que vous gardez secrète). ```mermaid flowchart LR - subgraph "Vos Clés" - SK[Clé de Service
~/.config/solana/id.json] - MK[Clé de Publication de Métriques
~/.config/doublezero/metrics-publisher.json] + subgraph "Vos clés" + SK[Clé de service
~/.config/solana/id.json] + MK[Clé de publication de métriques
~/.config/doublezero/metrics-publisher.json] + RK[Clé de gestionnaire de récompenses
conserver hors ligne] end SK -->|Utilisée pour| CLI[Commandes CLI
doublezero device create
doublezero link create] - MK -->|Utilisée pour| TEL[Agent de Télémétrie
Soumet les métriques onchain] + MK -->|Utilisée pour| TEL[Telemetry Agent
Soumet les métriques on-chain] + RK -->|Utilisée pour| REW[Portail de récompenses
Définit les portefeuilles destinataires] ``` -### Étape 2.1 : Générer Votre Clé de Service +!!! note "Gardez la clé de gestionnaire de récompenses séparée" + La clé de service et la clé de publication de métriques se trouvent sur votre serveur de gestion et votre switch. La clé de gestionnaire de récompenses contrôle où va votre argent, alors gardez-la hors de ces machines. Elle n'est nécessaire que lorsque vous modifiez vos portefeuilles destinataires. + +### Étape 2.1 : Générer votre clé de service C'est votre identité principale pour interagir avec DoubleZero. @@ -182,111 +229,166 @@ C'est votre identité principale pour interagir avec DoubleZero. doublezero keygen ``` -Cela crée une paire de clés à l'emplacement par défaut. La sortie montre votre **clé publique** — c'est ce que vous partagerez avec DZF. +Cela crée une paire de clés à l'emplacement par défaut. La sortie affiche votre **clé publique** — c'est ce que vous partagerez avec la DZF. -### Étape 2.2 : Générer Votre Clé de Publication de Métriques +### Étape 2.2 : Générer votre clé de publication de métriques -Cette clé est utilisée par l'Agent de Télémétrie pour signer les soumissions de métriques. +Cette clé est utilisée par le Telemetry Agent pour signer les soumissions de métriques. ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Étape 2.3 : Soumettre les Clés à DZF +### Étape 2.3 : Créer votre portefeuille de gestionnaire de récompenses + +C'est la troisième clé. Elle contrôle quels portefeuilles reçoivent vos récompenses, et ne les détient jamais elle-même. + +Créez un portefeuille Solana que vous contrôlez et avec lequel vous pouvez signer, puis approvisionnez-le d'environ 0,01 SOL pour couvrir les frais de transaction. Un portefeuille matériel est un bon choix. Ne réutilisez pas votre clé de service. + +Vous n'avez besoin du portefeuille qu'à ce stade. Vous définirez les portefeuilles qui reçoivent effectivement vos récompenses à l'[Étape 2.7](#etape-27-definir-vos-destinataires-de-recompenses), après que la DZF a enregistré cette clé. + +### Étape 2.4 : Soumettre les clés à la DZF Contactez la DoubleZero Foundation ou Malbec Labs et fournissez : 1. Votre **clé publique de service** -2. Votre **nom d'utilisateur GitHub** (pour l'accès au dépôt) +2. Votre **clé publique de gestionnaire de récompenses** (de l'Étape 2.3) +3. Votre **nom d'utilisateur GitHub** (pour l'accès au dépôt) + +Envoyez les trois ensemble. La DZF enregistre la clé de service et la clé de gestionnaire de récompenses dans des transactions on-chain séparées, donc les envoyer en même temps évite un aller-retour. + +!!! danger "Clés publiques uniquement" + N'envoyez jamais une clé privée ou un fichier de paire de clés à qui que ce soit, y compris à la DZF. La DZF n'a jamais besoin que de vos clés publiques. Ils vont : -- Créer votre **compte de contributeur** onchain -- Accorder l'accès au **dépôt des contributeurs** privé +- Créer votre **compte contributeur** on-chain +- Enregistrer votre **clé de gestionnaire de récompenses** associée à votre clé de service +- Accorder l'accès au **dépôt privé des contributeurs** -### Étape 2.4 : Vérifier Votre Compte +### Étape 2.5 : Vérifier votre compte -Une fois confirmé, vérifiez que votre compte de contributeur existe : +Une fois confirmé, vérifiez que votre compte contributeur existe : ```bash doublezero contributor list ``` -Vous devriez voir votre code de contributeur dans la liste. +Vous devriez voir votre code contributeur dans la liste. + +Vérifiez également que votre clé de gestionnaire de récompenses a été enregistrée : + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` + +La colonne `manager` devrait afficher votre clé publique de gestionnaire de récompenses. Si elle est vide, demandez à la DZF de compléter cette étape. -### Étape 2.5 : Accéder au Dépôt des Contributeurs +### Étape 2.6 : Accéder au dépôt des contributeurs Le dépôt [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contient : -- Configurations de base des dispositifs -- Profils TCAM -- Configurations ACL -- Instructions de configuration supplémentaires +- Les configurations de base des appareils +- Les profils TCAM +- Les configurations ACL +- Des instructions de configuration supplémentaires + +Suivez les instructions qui s'y trouvent pour la configuration spécifique à votre appareil. + +### Étape 2.7 : Définir vos destinataires de récompenses -Suivez les instructions là-bas pour la configuration spécifique au dispositif. +Indiquez maintenant quels portefeuilles reçoivent vos récompenses, et dans quelles proportions. Faites-le avant que votre appareil ne commence à acheminer du trafic. Les récompenses s'accumulent dès que vos liens sont actifs, mais le protocole ne peut pas les verser tant que vous n'avez pas désigné de portefeuilles destinataires. + +Connectez-vous à [doublezero.xyz/rewards](https://doublezero.xyz/rewards) avec votre portefeuille de gestionnaire de récompenses, sélectionnez votre clé de service, puis saisissez chaque portefeuille destinataire et son pourcentage. Les pourcentages doivent totaliser 100. + +!!! warning "Chaque destinataire a besoin d'un compte de jetons 2Z" + Le protocole envoie les 2Z avec un transfert de jetons simple et ne crée pas le compte de jetons pour vous. Un portefeuille destinataire sans compte de jetons 2Z entraîne l'échec du versement de cette époque. + +Voir [Gestion des récompenses](contribute-rewards.md) pour le guide complet, y compris l'alternative CLI, comment vérifier le compte de jetons et comment vérifier le résultat. --- -## Phase 3 : Provisionnement du Dispositif +## Phase 3 : Provisionnement de l'appareil -Vous allez maintenant enregistrer votre dispositif physique sur la blockchain et configurer ses interfaces. +Vous allez maintenant enregistrer votre appareil physique sur la blockchain et configurer ses interfaces. -### Comprendre les Types de Dispositifs +### Comprendre les types d'appareils + +**Edge** — accepte uniquement les connexions utilisateur ```mermaid -flowchart TB - subgraph "Dispositif Périphérique" - E[DZD Périphérique] - EU[Les utilisateurs se connectent ici] - EU --> E - E <-->|Lien DZX| ED[Autre DZD] +flowchart LR + subgraph EDZD[DZD Edge] + E_CYOA["Interface DIA · CYOA"] + E_TUN["Loopback100/101 + (point de terminaison tunnel utilisateur)"] + E_DZX["Interface lien DZX"] + E_CYOA --- E_TUN end + EU["Utilisateurs"] -.|Tunnel GRE|.-> E_CYOA + E_DZX <-->|Lien DZX| ED["DZD (contributeur différent)"] +``` + +**Transit** — achemine le trafic entre appareils, pas de connexions utilisateur - subgraph "Dispositif de Transit" - T[DZD de Transit] - T <-->|Lien WAN| T2[Un autre DZD] - T <-->|Lien DZX| TD[Autre DZD] +```mermaid +flowchart LR + subgraph TDZD[DZD Transit] + T_WAN["Interface lien WAN"] + T_DZX["Interface lien DZX"] end + T_WAN <-->|Lien WAN| T2["DZD (même contributeur)"] + T_DZX <-->|Lien DZX| TD["DZD (contributeur différent)"] +``` + +**Hybride** — connexions utilisateur et backbone, le plus courant - subgraph "Dispositif Hybride" - H[DZD Hybride] - HU[Les utilisateurs se connectent ici] - HU --> H - H <-->|Lien WAN| H2[Un autre DZD] - H <-->|Lien DZX| HD[Autre DZD] +```mermaid +flowchart LR + subgraph HDZD[DZD Hybride] + H_CYOA["Interface DIA · CYOA"] + H_TUN["Loopback100/101 + (point de terminaison tunnel utilisateur)"] + H_WAN["Interface lien WAN"] + H_DZX["Interface lien DZX"] + H_CYOA --- H_TUN end + HU["Utilisateurs"] -.|Tunnel GRE|.-> H_CYOA + H_WAN <-->|Lien WAN| H2["DZD (même contributeur)"] + H_DZX <-->|Lien DZX| HD["DZD (contributeur différent)"] ``` -| Type | Ce Qu'il Fait | Quand l'Utiliser | -|------|--------------|-----------------| -| **Périphérique** | Accepte uniquement les connexions utilisateurs | Emplacement unique, orienté utilisateurs uniquement | -| **Transit** | Déplace le trafic entre dispositifs | Connectivité backbone, sans utilisateurs | -| **Hybride** | Connexions utilisateurs ET backbone | Le plus courant — fait tout | +| Type | Ce qu'il fait | Quand l'utiliser | +|------|--------------|-------------| +| **Edge** | Accepte uniquement les connexions utilisateur | Emplacement unique, orienté utilisateur uniquement | +| **Transit** | Achemine le trafic entre appareils | Connectivité backbone, pas d'utilisateurs | +| **Hybride** | Connexions utilisateur ET backbone | Le plus courant — fait tout | -### Étape 3.1 : Trouver Votre Emplacement et Exchange +### Étape 3.1 : Trouver votre emplacement et votre point d'échange -Avant de créer votre dispositif, recherchez les codes de votre emplacement de centre de données et de l'exchange le plus proche : +Avant de créer votre appareil, recherchez les codes de votre emplacement de data center et du point d'échange le plus proche : ```bash -# Lister les emplacements disponibles (centres de données) +# Lister les emplacements disponibles (data centers) doublezero location list -# Lister les exchanges disponibles (points d'interconnexion) +# Lister les points d'échange disponibles (points d'interconnexion) doublezero exchange list ``` -### Étape 3.2 : Créer Votre Dispositif Onchain +### Étape 3.2 : Créer votre appareil on-chain -Enregistrez votre dispositif sur la blockchain : +Enregistrez votre appareil sur la blockchain : ```bash doublezero device create \ - --code \ + --code \ --contributor \ --device-type hybrid \ --location \ - --exchange \ - --public-ip \ + --exchange \ + --public-ip \ --dz-prefixes ``` @@ -309,34 +411,34 @@ doublezero device create \ Signature: 4vKz8H...truncated...7xPq2 ``` -Vérifiez que votre dispositif a été créé : +Vérifiez que votre appareil a été créé : ```bash doublezero device list | grep nyc-dz001 ``` -**Paramètres expliqués :** +**Explication des paramètres :** -| Paramètre | Ce Qu'il Signifie | -|-----------|------------------| -| `--code` | Un nom unique pour votre dispositif (par exemple, `nyc-dz001`) | -| `--contributor` | Votre code de contributeur (donné par DZF) | -| `--device-type` | `hybrid`, `transit`, ou `edge` | -| `--location` | Code du centre de données de `location list` | -| `--exchange` | Code de l'exchange le plus proche de `exchange list` | -| `--public-ip` | L'IP publique où les utilisateurs se connectent à votre dispositif via internet | -| `--dz-prefixes` | Votre bloc IP alloué pour les utilisateurs | +| Paramètre | Signification | +|-----------|---------------| +| `--code` | Un nom unique pour votre appareil (ex. `nyc-dz001`) | +| `--contributor` | Votre code contributeur (fourni par la DZF) | +| `--device-type` | `hybrid`, `transit` ou `edge` | +| `--location` | Code du data center depuis `location list` | +| `--exchange` | Code du point d'échange le plus proche depuis `exchange list` | +| `--public-ip` | L'IP publique par laquelle les utilisateurs se connectent à votre appareil via internet | +| `--dz-prefixes` | Votre bloc d'IP alloué pour les utilisateurs | -### Étape 3.3 : Créer les Interfaces Loopback Requises +### Étape 3.3 : Créer les interfaces loopback requises -Chaque dispositif a besoin de deux interfaces loopback pour le routage interne : +Chaque appareil a besoin de deux interfaces loopback pour le routage interne : ```bash # Loopback VPNv4 -doublezero device interface create Loopback255 --loopback-type vpnv4 +doublezero device interface create Loopback255 --loopback-type vpnv4 # Loopback IPv4 -doublezero device interface create Loopback256 --loopback-type ipv4 +doublezero device interface create Loopback256 --loopback-type ipv4 ``` **Sortie attendue (pour chaque commande) :** @@ -345,13 +447,20 @@ doublezero device interface create Loopback256 --loopback-type Signature: 3mNx9K...truncated...8wRt5 ``` -### Étape 3.4 : Créer les Interfaces Physiques +### Étape 3.4 : Créer les interfaces physiques + +Enregistrez les interfaces physiques qui seront utilisées pour les liens WAN ou DZX. Ces interfaces doivent exister on-chain avant que vous puissiez créer un lien qui les référence. À cette étape, vous enregistrez uniquement l'interface et sa bande passante ; le lien est créé dans une étape ultérieure. -Enregistrez les ports physiques que vous utiliserez : +```bash +doublezero device interface create \ + --bandwidth +``` + +**Exemple :** ```bash -# Interface de base -doublezero device interface create Ethernet1/1 +doublezero device interface create nyc-dz001 Ethernet1/1 \ + --bandwidth 10Gbps ``` **Sortie attendue :** @@ -360,49 +469,51 @@ doublezero device interface create Ethernet1/1 Signature: 7pQw2R...truncated...4xKm9 ``` -### Étape 3.5 : Créer l'Interface CYOA (pour les dispositifs Périphériques/Hybrides) +Répétez cette opération pour chaque interface qui sera utilisée comme point de terminaison d'un lien WAN ou DZX. Les interfaces CYOA et DIA sont enregistrées séparément à l'étape suivante. + +### Étape 3.5 : Créer l'interface CYOA (pour les appareils Edge/Hybride) -Les DZDs hybrides et périphériques ont besoin de **deux adresses IP publiques** sur lesquelles les utilisateurs terminent leurs tunnels GRE. Les utilisateurs peuvent se connecter via unicast, multicast, ou les deux, et quelle IP sert quel objectif est tournée par utilisateur. +Les DZD hybrides et edge ont besoin de **deux adresses IP publiques** sur lesquelles les utilisateurs terminent leurs tunnels GRE. Les utilisateurs peuvent se connecter en unicast, multicast, ou les deux, et quelle IP sert quel objectif alterne par utilisateur. -Les deux IPs doivent être enregistrées avec `--user-tunnel-endpoint true`, soit sur une interface physique, soit sur un loopback. Cela inclut l'IP que vous avez fournie lors de la création du dispositif ; cette IP doit encore être explicitement enregistrée ici. +Les deux IP doivent être enregistrées avec `--user-tunnel-endpoint true`, soit sur une interface physique, soit sur un loopback. Cela inclut l'IP que vous avez fournie lors de la création de l'appareil ; cette IP doit tout de même être explicitement enregistrée ici. -Si vous êtes limité en IPs, vous pouvez utiliser le premier `/32` de votre préfixe DZ comme l'une des deux IPs. +Si vous êtes limité en IP, vous pouvez utiliser le premier `/32` de votre préfixe DZ comme l'une des deux IP. #### CYOA et DIA -| Type | Flag | Objectif | -|------|------|----------| +| Type | Indicateur | Objectif | +|------|------|---------| | DIA | `--interface-dia dia` | Marque le port comme accès internet direct | -| CYOA | `--interface-cyoa ` | Déclare comment les utilisateurs connectent des tunnels GRE à votre dispositif | +| CYOA | `--interface-cyoa ` | Déclare comment les utilisateurs connectent les tunnels GRE à votre appareil | -Le flag CYOA est toujours défini sur une **interface physique** (port Ethernet ou port channel). Jamais sur un loopback. +L'indicateur CYOA est toujours défini sur une **interface physique** (port Ethernet ou port channel). Jamais sur un loopback. -| Sous-type CYOA | Quand utiliser | -|---------------|---------------| -| `gre-over-dia` | Les utilisateurs se connectent via internet public. Le plus courant. | -| `gre-over-private-peering` | Les utilisateurs se connectent via un cross-connect direct ou un circuit privé | -| `gre-over-public-peering` | Les utilisateurs peerent avec vous à un Internet Exchange (IX) | -| `gre-over-fabric` | Les utilisateurs sont co-localisés et se connectent via un fabric local | -| `gre-over-cable` | Connexion câble directe à un seul utilisateur dédié | +| Sous-type CYOA | Quand l'utiliser | +|-------------|-------------| +| `gre-over-dia` | Les utilisateurs se connectent via l'internet public. Le plus courant. | +| `gre-over-private-peering` | Les utilisateurs se connectent via une interconnexion directe ou un circuit privé | +| `gre-over-public-peering` | Les utilisateurs peerent avec vous dans un point d'échange internet (IX) | +| `gre-over-fabric` | Les utilisateurs sont colocalisés et se connectent via un fabric local | +| `gre-over-cable` | Connexion par câble direct vers un seul utilisateur dédié | #### Scénario A : Interface physique unique -Un uplink physique vers l'ISP. Ethernet1/1 est l'interface CYOA et DIA et porte l'une des deux IPs publiques. Loopback100 porte la deuxième IP publique. +Une seule liaison montante physique vers le FAI. Ethernet1/1 est l'interface CYOA et DIA et porte l'une des deux IP publiques. Loopback100 porte la seconde IP publique. ```mermaid flowchart LR - USERS(["Utilisateurs Finaux"]) + USERS(["Utilisateurs finaux"]) subgraph DZD["DZD"] E1["Eth1/1 203.0.113.1/30 - CYOA · DIA · user tunnel endpoint"] + CYOA · DIA · point de terminaison tunnel utilisateur"] LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n point de terminaison tunnel utilisateur"] E1 --- LO end - ISP["Routeur ISP + ISP["Routeur FAI 203.0.113.2/30"] ISP -- "10GbE" --- E1 @@ -412,10 +523,10 @@ flowchart LR | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sous-réseau assigné par le contributeur | vitesse du port | taux engagé | `bgp` ou `static` | `true` | +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sous-réseau assigné par le contributeur | vitesse du port | débit garanti | `bgp` ou `static` | `true` | | Loopback100 | — | — | votre /32 public | `0bps` | — | — | `true` | -Exemple de commandes pour le Scénario A : +Exemple de commandes à exécuter pour le Scénario A : ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -434,24 +545,24 @@ doublezero device interface create mydzd-nyc01 Loopback100 \ #### Scénario B : Port channel (LAG) -Le DZD se connecte au dispositif upstream via un port channel avec une IP. Le port channel porte une IP publique et est le point de terminaison CYOA. Loopback100 porte la deuxième IP publique. +Le DZD se connecte à l'équipement amont via un port channel avec une IP. Le port channel porte une IP publique et constitue le point de terminaison CYOA. Loopback100 porte la seconde IP publique. ```mermaid flowchart LR - USERS(["Utilisateurs Finaux"]) + USERS(["Utilisateurs finaux"]) - subgraph SW["Routeur/Switch Upstream"] + subgraph SW["Routeur / Switch amont"] SWPC(["bond0 203.0.113.2/30"]) end subgraph DZD["DZD"] - subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · user tunnel endpoint"] + subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · point de terminaison tunnel utilisateur"] E1["Eth1/1"] E2["Eth2/1"] end LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n point de terminaison tunnel utilisateur"] PC --- LO end @@ -461,552 +572,4 @@ flowchart LR ``` | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | IP/sous-réseau assigné par le contributeur | vitesse LAG combinée | taux engagé | `bgp` ou `static` | `true` | -| Loopback100 | — | — | votre /32 public | `0bps` | — | — | `true` | - -Exemple de commandes pour le Scénario B : -```bash -doublezero device interface create mydzd-fra01 Port-Channel1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 20Gbps \ - --cir 2Gbps \ - --routing-mode bgp \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-fra01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -#### Scénario C : Double uplinks physiques vers des routeurs séparés - -Chaque interface physique se connecte à un routeur upstream différent. Les deux IPs publiques se trouvent sur Loopback100 et Loopback101, toutes deux enregistrées comme points de terminaison de tunnel utilisateur. - -```mermaid -flowchart LR - USERS(["Utilisateurs Finaux"]) - - RA["Routeur A - 203.0.113.2/30"] - RB["Routeur B - 203.0.113.6/30"] - - subgraph DZD["DZD"] - E1["Eth1/1 - 203.0.113.1/30 - CYOA · DIA"] - E2["Eth2/1 - 203.0.113.5/30 - CYOA · DIA"] - LO0["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - LO1["Loopback101 - 198.51.100.2/32\n user tunnel endpoint"] - E1 --> LO0 - E2 --> LO1 - end - - RA -- "10GbE" --- E1 - RB -- "10GbE" --- E2 - USERS -. "Tunnels GRE" .-> LO0 - USERS -. "Tunnels GRE" .-> LO1 -``` - -| Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sous-réseau assigné par le contributeur | vitesse du port | taux engagé | `bgp` ou `static` | — | -| Ethernet2/1 | `gre-over-dia` | `dia` | IP/sous-réseau assigné par le contributeur | vitesse du port | taux engagé | `bgp` ou `static` | — | -| Loopback100 | — | — | votre /32 public | `0bps` | — | — | `true` | -| Loopback101 | — | — | votre /32 public | `0bps` | — | — | `true` | - -Exemple de commandes pour le Scénario C : -```bash -doublezero device interface create mydzd-ams01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Ethernet2/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.5/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-ams01 Loopback101 \ - --ip-net 198.51.100.2/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -### Étape 3.6 : Vérifier Votre Dispositif - -```bash -doublezero device list -``` - -**Exemple de sortie :** - -``` - account | code | contributor | location | exchange | device_type | public_ip | dz_prefixes | users | max_users | status | health | mgmt_vrf | owner - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -Votre dispositif devrait apparaître avec le statut `activated`. - ---- - -## Phase 4 : Établissement des Liens et Installation des Agents - -Les liens connectent votre dispositif au reste du réseau DoubleZero. - -### Comprendre les Liens - -```mermaid -flowchart LR - subgraph "Votre Réseau" - D1[Votre DZD 1
NYC] - D2[Votre DZD 2
LAX] - end - - subgraph "Autre Contributeur" - O1[Leur DZD
NYC] - end - - D1 ---|Lien WAN
Même contributeur| D2 - D1 ---|Lien DZX
Contributeurs différents| O1 -``` - -| Type de Lien | Connecte | Acceptation | -|-------------|----------|-------------| -| **Lien WAN** | Deux de VOS dispositifs | Automatique (vous possédez les deux) | -| **Lien DZX** | Votre dispositif à un AUTRE contributeur | Nécessite leur acceptation | - -### Étape 4.1 : Créer des Liens WAN (si vous avez plusieurs dispositifs) - -Les liens WAN connectent vos propres dispositifs : - -```bash -doublezero link create wan \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --side-z-interface \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 20 \ - --jitter-ms 1 -``` - -**Exemple :** - -```bash -doublezero link create wan \ - --code nyc-lax-wan01 \ - --contributor acme \ - --side-a nyc-dz001 \ - --side-a-interface Ethernet3/1 \ - --side-z lax-dz001 \ - --side-z-interface Ethernet3/1 \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 65 \ - --jitter-ms 1 -``` - -**Sortie attendue :** - -``` -Signature: 5tNm7K...truncated...9pRw2 -``` - -### Étape 4.2 : Créer des Liens DZX - -Les liens DZX connectent votre dispositif directement au DZD d'un autre contributeur : - -```bash -doublezero link create dzx \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --bandwidth \ - --mtu \ - --delay-ms \ - --jitter-ms -``` - -**Sortie attendue :** - -``` -Signature: 8mKp3W...truncated...2nRx7 -``` - -Après avoir créé un lien DZX, l'autre contributeur doit l'accepter : - -```bash -# L'AUTRE contributeur exécute ceci -doublezero link accept \ - --code \ - --side-z-interface -``` - -**Sortie attendue (pour le contributeur qui accepte) :** - -``` -Signature: 6vQt9L...truncated...3wPm4 -``` - -### Étape 4.3 : Vérifier les Liens - -```bash -doublezero link list -``` - -**Exemple de sortie :** - -``` - account | code | contributor | side_a_name | side_a_iface_name | side_z_name | side_z_iface_name | link_type | bandwidth | mtu | delay_ms | jitter_ms | delay_override_ms | tunnel_id | tunnel_net | status | health | owner - 8vkYpXaBW8RuknJq... | nyc-dz001:lax-dz001 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -Les liens devraient afficher le statut `activated` une fois les deux côtés configurés. - ---- - -### Installation des Agents - -Deux agents logiciels s'exécutent sur votre DZD : - -```mermaid -flowchart TB - subgraph "Votre DZD" - CA[Agent de Configuration] - TA[Agent de Télémétrie] - HW[Matériel/Logiciel du Commutateur] - end - - CA -->|Interroge la config| CTRL[Service Contrôleur] - CA -->|Applique la config| HW - - HW -->|Métriques| TA - TA -->|Soumet onchain| BC[Registre DoubleZero] -``` - -| Agent | Ce Qu'il Fait | -|-------|--------------| -| **Agent de Configuration** | Récupère la configuration depuis le contrôleur, l'applique à votre commutateur | -| **Agent de Télémétrie** | Mesure la latence/perte vers les autres dispositifs, rapporte les métriques onchain | - -### Étape 4.4 : Installer l'Agent de Configuration - -#### Activer l'API sur votre commutateur - -Ajouter à la configuration EOS : - -``` -management api eos-sdk-rpc - transport grpc eapilocal - localhost loopback vrf default - service all - no disabled -``` - -!!! note "Note VRF" - Remplacez `default` par votre nom de VRF de gestion si différent (par exemple, `management`). - -#### Télécharger et installer l'agent - -```bash -# Entrer dans bash sur le commutateur -switch# bash -$ sudo bash -# cd /mnt/flash -# wget AGENT_DOWNLOAD_URL -# exit -$ exit - -# Installer comme extension EOS -switch# copy flash:AGENT_FILENAME extension: -switch# extension AGENT_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Vérifier l'extension - -```bash -switch# show extensions -``` - -Le Statut devrait être "A, I, B" : - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -AGENT_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configurer et démarrer l'agent - -Ajouter à la configuration EOS : - -``` -daemon doublezero-agent - exec /usr/local/bin/doublezero-agent -pubkey - no shut -``` - -!!! note "Note VRF" - Si votre VRF de gestion n'est pas `default` (c'est-à-dire que le namespace n'est pas `ns-default`), préfixez la commande exec avec `exec /sbin/ip netns exec ns-`. Par exemple, si votre VRF est `management` : - ``` - daemon doublezero-agent - exec /sbin/ip netns exec ns-management /usr/local/bin/doublezero-agent -pubkey - no shut - ``` - -Obtenez la pubkey de votre dispositif depuis `doublezero device list` (colonne `account`). - -#### Vérifier qu'il fonctionne - -```bash -switch# show agent doublezero-agent logs -``` - -Vous devriez voir "Starting doublezero-agent" et des connexions réussies au contrôleur. - -### Étape 4.5 : Installer l'Agent de Télémétrie - -#### Copier la clé de publication de métriques sur votre dispositif - -```bash -scp ~/.config/doublezero/metrics-publisher.json :/mnt/flash/metrics-publisher-keypair.json -``` - -#### Enregistrer la publication de métriques onchain - -```bash -doublezero device update \ - --pubkey \ - --metrics-publisher -``` - -Obtenez la pubkey depuis votre fichier metrics-publisher.json. - -#### Télécharger et installer l'agent - -```bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget TELEMETRY_DOWNLOAD_URL -# exit -$ exit - -# Installer comme extension EOS -switch# copy flash:TELEMETRY_FILENAME extension: -switch# extension TELEMETRY_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Vérifier l'extension - -```bash -switch# show extensions -``` - -Le Statut devrait être "A, I, B" : - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -TELEMETRY_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configurer et démarrer l'agent - -Ajouter à la configuration EOS : - -``` -daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut -``` - -!!! note "Note VRF" - Si votre VRF de gestion n'est pas `default` (c'est-à-dire que le namespace n'est pas `ns-default`), ajoutez `--management-namespace ns-` à la commande exec. Par exemple, si votre VRF est `management` : - ``` - daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --management-namespace ns-management --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut - ``` - -#### Vérifier qu'il fonctionne - -```bash -switch# show agent doublezero-telemetry logs -``` - -Vous devriez voir "Starting telemetry collector" et "Starting submission loop". - ---- - -## Phase 5 : Rodage du Lien - -!!! warning "Tous les nouveaux liens doivent être rodés avant de transporter du trafic" - Les nouveaux liens doivent être **drainés pendant au moins 24 heures** avant d'être activés pour le trafic de production. Cette exigence de rodage est définie dans [RFC12: Network Provisioning](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md), qui spécifie ~200 000 slots du Registre DZ (~20 heures) de métriques propres avant qu'un lien soit prêt pour le service. - -Avec les agents installés et en cours d'exécution, surveillez vos liens sur [metrics.doublezero.xyz](https://metrics.doublezero.xyz) pendant au moins 24 heures consécutives : - -- Tableau de bord **"DoubleZero Device-Link Latencies"** — vérifiez **zéro perte de paquets** sur le lien au fil du temps -- Tableau de bord **"DoubleZero Network Metrics"** — vérifiez **zéro erreurs** sur vos liens - -Ne dédrainer le lien qu'une fois que la période de rodage montre un lien propre avec zéro perte et zéro erreurs. - ---- - -## Phase 6 : Vérification et Activation - -Parcourez cette liste de contrôle pour confirmer que tout fonctionne. - -!!! warning "Votre dispositif commence verrouillé (`max_users = 0`)" - Lorsqu'un dispositif est créé, `max_users` est fixé à **0** par défaut. Cela signifie qu'aucun utilisateur ne peut encore s'y connecter. C'est intentionnel — vous devez vérifier que tout fonctionne avant d'accepter le trafic utilisateurs. - - **Avant de définir `max_users` au-dessus de 0, vous devez :** - - 1. Confirmer que tous les liens ont complété leur **rodage de 24 heures** avec zéro perte/erreurs sur [metrics.doublezero.xyz](https://metrics.doublezero.xyz) - 2. **Coordonner avec DZ/Malbec Labs** pour exécuter un test de connectivité : - - Un utilisateur de test peut-il se connecter à votre dispositif ? - - L'utilisateur reçoit-il des routes sur le réseau DZ ? - - L'utilisateur peut-il router le trafic sur le réseau DZ de bout en bout ? - 3. Seulement après que DZ/ML confirme que les tests réussissent, définissez max_users à 96 : - - ```bash - doublezero device update --pubkey --max-users 96 - ``` - -### Vérifications du Dispositif - -```bash -# Votre dispositif devrait apparaître avec le statut "activated" -doublezero device list | grep -``` - -**Sortie attendue :** - -``` - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -```bash -# Vos interfaces devraient être listées -doublezero device interface list | grep -``` - -**Sortie attendue :** - -``` - nyc-dz001 | Loopback255 | loopback | vpnv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.91/32 | 56 | false | activated - nyc-dz001 | Loopback256 | loopback | ipv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.100/32 | 0 | false | activated - nyc-dz001 | Ethernet1/1 | physical | none | none | none | 0 | 0 | 1500 | static | 0 | | 0 | false | activated -``` - -### Vérifications des Liens - -```bash -# Les liens devraient afficher le statut "activated" -doublezero link list | grep -``` - -**Sortie attendue :** - -``` - 8vkYpXaBW8RuknJq... | nyc-lax-wan01 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -### Vérifications des Agents - -Sur le commutateur : - -```bash -# L'agent de configuration devrait afficher des extractions de configuration réussies -switch# show agent doublezero-agent logs | tail -20 - -# L'agent de télémétrie devrait afficher des soumissions réussies -switch# show agent doublezero-telemetry logs | tail -20 -``` - -### Diagramme de Vérification Finale - -```mermaid -flowchart TB - subgraph "Liste de Vérification" - D[Statut Dispositif : activé ?] - I[Interfaces : enregistrées ?] - L[Liens : activés ?] - CA[Agent de Config : récupération de config ?] - TA[Agent de Télémétrie : soumission de métriques ?] - end - - D --> PASS - I --> PASS - L --> PASS - CA --> PASS - TA --> PASS - - PASS[Toutes les Vérifications Réussies] --> NOTIFY[Notifier DZF/Malbec Labs
Vous êtes techniquement prêt !] -``` - ---- - -## Dépannage - -### La création du dispositif échoue - -- Vérifiez que votre clé de service est autorisée (`doublezero contributor list`) -- Vérifiez que les codes d'emplacement et d'exchange sont valides -- Assurez-vous que le préfixe DZ est une plage IP publique valide - -### Lien bloqué dans le statut "requested" - -- Les liens DZX nécessitent l'acceptation de l'autre contributeur -- Contactez-les pour exécuter `doublezero link accept` - -### L'Agent de Configuration ne se connecte pas - -- Vérifiez que le réseau de gestion a accès à internet -- Vérifiez que la configuration VRF correspond à votre configuration -- Assurez-vous que la pubkey du dispositif est correcte - -### L'Agent de Télémétrie ne soumet pas - -- Vérifiez que la clé de publication de métriques est enregistrée onchain -- Vérifiez que le fichier de paire de clés existe sur le commutateur -- Assurez-vous que la pubkey du compte du dispositif est correcte - ---- - -## Prochaines Étapes - -- Consultez le [Guide des Opérations](contribute-operations.md) pour les mises à niveau des agents et la gestion des liens -- Consultez le [Glossaire](glossary.md) pour les définitions des termes -- Contactez DZF/Malbec Labs si vous rencontrez des problèmes +|-----------| \ No newline at end of file diff --git a/docs/contribute-provisioning.it.md b/docs/contribute-provisioning.it.md index f19005f..eb9ce41 100644 --- a/docs/contribute-provisioning.it.md +++ b/docs/contribute-provisioning.it.md @@ -1,14 +1,51 @@ -# Guida al Provisioning dei Dispositivi -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Guida passo-passo per il provisioning di un DoubleZero Device (DZD) e la registrazione delle sue interfacce e ruoli on-chain. +--- +# Guida al Provisioning dei Dispositivi -Questa guida illustra il provisioning di un DoubleZero Device (DZD) dall'inizio alla fine. Ogni fase corrisponde alla [Checklist di Onboarding](contribute-overview.md#onboarding-checklist). +Questa guida ti accompagna nel provisioning di un DoubleZero Device (DZD) dall'inizio alla fine. Ogni fase corrisponde alla [Checklist di Onboarding](contribute-overview.md#onboarding-checklist). --- -## Come Si Incastra Tutto +## Come si integra il tutto + +Questa guida ti accompagna nella registrazione della tua infrastruttura on-chain in modo che la rete DoubleZero possa instradare il traffico attraverso di essa. Più la registrazione del tuo dispositivo è completa, più questo risulta utile per la rete. Una rappresentazione on-chain completa del tuo dispositivo consente un miglior troubleshooting, una migliore pianificazione della capacità e permette al controller di prendere decisioni informate. Nel tempo, l'obiettivo è che il controller assuma una parte sempre maggiore della responsabilità di configurazione. + +### Concetti chiave + +**Interfacce** + +Le interfacce su un DZD si presentano in diverse forme: porte Ethernet, port channel (LAG composti da più porte Ethernet) e loopback. Ogni interfaccia che svolge un ruolo nella rete deve essere registrata on-chain con i flag appropriati affinché il protocollo sappia quale funzione svolge. + +Le porte Ethernet e i port channel possono svolgere i seguenti ruoli: + +| Flag | Significato | +|------|-------------| +| `--interface-dia dia` | Contrassegna l'interfaccia come uplink di accesso diretto a internet | +| `--interface-cyoa ` | Dichiara come gli utenti stabiliscono i tunnel GRE attraverso questa interfaccia (es. tramite internet pubblico, tramite un link di peering privato) | +| `--user-tunnel-endpoint true` | Questa interfaccia possiede un IP pubblico su cui gli utenti terminano i tunnel GRE | -Prima di entrare nei dettagli, ecco il quadro generale di ciò che stai costruendo: +Le interfacce utilizzate per link WAN o DZX non hanno un flag specifico: vengono registrate con la loro larghezza di banda e poi referenziate quando il link viene creato. + +Le interfacce loopback svolgono diversi scopi: + +| Loopback | Significato | +|----------|-------------| +| **Loopback100 / 101** | Portano IP pubblici su cui gli utenti terminano i tunnel GRE. Registrate con `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Registrata affinché il controller possa assegnare un IP utilizzato per il router ID BGP, il peering VPN-IPv4 (unicast), l'identità IS-IS e il segment routing | +| **Loopback256** (`ipv4`) | Registrata affinché il controller possa assegnare un IP utilizzato per il peering BGP IPv4 (multicast) e le sessioni MSDP | + +**Link** + +I link vengono registrati separatamente dalle interfacce, e le interfacce devono esistere on-chain prima che un link possa referenziarle. Quando crei un link WAN o DZX, specifichi un'interfaccia già registrata come endpoint fisico del link. Non tutte le interfacce sono associate a un link: le interfacce DIA, CYOA e loopback non sono collegate a un link. + +| Termine | Significato | +|---------|-------------| +| **WAN Link** | Un link tra due dei tuoi DZD | +| **DZX Link** | Un link tra il tuo DZD e il DZD di un altro contributore | + +### Panoramica dell'architettura ```mermaid flowchart TB @@ -18,45 +55,48 @@ flowchart TB subgraph Your Infrastructure MGMT[Management Server
DoubleZero CLI] - DZD[Your DZD
Arista Switch] - DZD ---|WAN Link| DZD2[Your other DZD] + subgraph DZD[Your DZD] + CYOA["DIA · CYOA interface
(user-facing uplink)"] + WAN_INTF["WAN link interface"] + DZX_INTF["DZX link interface"] + LO100["Loopback100/101
(user tunnel endpoint)"] + end + DZD2[Your other DZD] end subgraph Other Contributor OtherDZD[Their DZD] end - subgraph Users - VAL[Validators] - RPC[RPC Nodes] - end + USERS["Users"] MGMT -.->|Registers devices,
links, interfaces| SC - DZD ---|DZX Link| OtherDZD - VAL ---|Connect via Internet| DZD - RPC ---|Connect via Internet| DZD + WAN_INTF ---|WAN Link| DZD2 + DZX_INTF ---|DZX Link| OtherDZD + USERS -.|GRE tunnel|.-> CYOA + CYOA ---|routes to| LO100 ``` --- ## Fase 1: Prerequisiti -Prima di poter effettuare il provisioning di un dispositivo, è necessario che l'hardware fisico sia configurato e alcuni indirizzi IP allocati. +Prima di poter effettuare il provisioning di un dispositivo, è necessario predisporre l'hardware fisico e allocare alcuni indirizzi IP. -### Cosa Ti Serve +### Cosa ti serve -| Requisito | Perché È Necessario | +| Requisito | Perché è necessario | |-----------|---------------------| | **Hardware DZD** | Switch Arista 7280CR3A (vedi [specifiche hardware](contribute.md#hardware-requirements)) | -| **Spazio Rack** | 4U con adeguato flusso d'aria | -| **Alimentazione** | Alimentazioni ridondanti, ~4KW raccomandato | -| **Accesso di Gestione** | Accesso SSH/console per configurare lo switch | -| **Connettività Internet** | Per la pubblicazione di metriche e per recuperare la configurazione dal controller | +| **Spazio Rack** | 1U per DZD, con flusso d'aria adeguato. Vedi [Rack e Alimentazione](contribute.md#rack-power-requirements) | +| **Alimentazione** | Due linee di alimentazione indipendenti, ciascuna in grado di sostenere l'intero carico da sola. Vedi [Rack e Alimentazione](contribute.md#rack-power-requirements) | +| **Accesso di gestione** | Accesso SSH/console per configurare lo switch | +| **Connettività Internet** | Per la pubblicazione delle metriche e per ottenere la configurazione dal controller | | **Blocco IPv4 Pubblico** | Minimo /29 per il pool di prefissi DZ (vedi sotto) | -### Installa la CLI DoubleZero +### Installare la CLI DoubleZero -La CLI DoubleZero (`doublezero`) viene utilizzata durante tutto il provisioning per registrare dispositivi, creare link e gestire il contributo. Deve essere installata su un **server di gestione o VM** — non sullo switch DZD stesso. Lo switch esegue solo il Config Agent e il Telemetry Agent (installati nella [Fase 4](#fase-4-stabilimento-del-link-e-installazione-degli-agent)). +La CLI DoubleZero (`doublezero`) viene utilizzata durante tutto il provisioning per registrare dispositivi, creare link e gestire il tuo contributo. Deve essere installata su un **server di gestione o una VM** — non sullo switch DZD stesso. Lo switch esegue solo il Config Agent e il Telemetry Agent (installati nella [Fase 4](#fase-4-creazione-dei-link-e-installazione-degli-agent)). **Ubuntu / Debian:** ```bash @@ -75,9 +115,9 @@ Verifica che il daemon sia in esecuzione: sudo systemctl status doublezerod ``` -### Comprendere il Tuo Prefisso DZ +### Comprendere il tuo prefisso DZ -Il tuo prefisso DZ è un blocco di indirizzi IP pubblici che il protocollo DoubleZero gestisce per l'allocazione degli IP. +Il tuo prefisso DZ è un blocco di indirizzi IP pubblici che il protocollo DoubleZero gestisce per l'allocazione IP. ```mermaid flowchart LR @@ -94,20 +134,19 @@ flowchart LR IP3 -->|Allocated to| U2[User 2] ``` -**Come vengono usati i prefissi DZ:** +**Come vengono utilizzati i prefissi DZ:** - **Primo IP**: Riservato per il tuo dispositivo (assegnato all'interfaccia Loopback100) -- **IP Rimanenti**: Allocati a specifici tipi di utenti che si connettono al tuo DZD: +- **IP rimanenti**: Allocati a specifici tipi di utenti che si connettono al tuo DZD: - Utenti `IBRLWithAllocatedIP` - - Utenti `EdgeFiltering` - - Publisher multicast + - Utenti `EdgeFiltering` (caso d'uso futuro) - **Utenti IBRL**: NON consumano da questo pool (usano il proprio IP pubblico) !!! warning "Regole del Prefisso DZ" - **NON PUOI usare questi indirizzi per:** + **NON puoi usare questi indirizzi per:** - - La tua infrastruttura di rete - - Link point-to-point sulle interfacce DIA + - Le tue apparecchiature di rete + - Link punto-punto sulle interfacce DIA - Interfacce di gestione - Qualsiasi infrastruttura al di fuori del protocollo DZ @@ -115,21 +154,23 @@ flowchart LR - Devono essere indirizzi IPv4 **globalmente instradabili (pubblici)** - Gli intervalli IP privati (10.x, 172.16-31.x, 192.168.x) vengono rifiutati dallo smart contract - - **Dimensione minima: /29** (8 indirizzi), prefissi più grandi preferiti (es. /28, /27) + - **Dimensione minima: /29** (8 indirizzi), prefissi più grandi sono preferibili (es. /28, /27) - L'intero blocco deve essere disponibile — non pre-allocare alcun indirizzo - Se hai bisogno di indirizzi per la tua infrastruttura (IP di interfaccia DIA, gestione, ecc.), usa un **pool di indirizzi separato**. + Se hai bisogno di indirizzi per le tue apparecchiature (IP delle interfacce DIA, gestione, ecc.), usa un **pool di indirizzi separato**. --- -## Fase 2: Configurazione dell'Account +## Fase 2: Configurazione dell'account + +In questa fase, crei le chiavi crittografiche che ti identificano te e i tuoi dispositivi sulla rete, e indichi dove devono essere pagati i tuoi reward. -In questa fase, crei le chiavi crittografiche che identificano te e i tuoi dispositivi sulla rete. +Da questa fase si ottengono tre chiavi: una chiave di servizio, una chiave per la pubblicazione delle metriche e una chiave per la gestione dei reward. Invia le chiavi pubbliche di tutte e tre alla DZF insieme nel [Passo 2.4](#passo-24-inviare-le-chiavi-alla-dzf). [Gestione dei Reward](contribute-rewards.md) copre in dettaglio il lato dei reward. -### Dove Eseguire la CLI +### Dove eseguire la CLI !!! warning "NON installare la CLI sul tuo switch" - La CLI DoubleZero (`doublezero`) deve essere installata su un **server di gestione o VM**, non sullo switch Arista. + La CLI DoubleZero (`doublezero`) deve essere installata su un **server di gestione o una VM**, non sul tuo switch Arista. ```mermaid flowchart LR @@ -148,33 +189,39 @@ In questa fase, crei le chiavi crittografiche che identificano te e i tuoi dispo TA -->|Submits metrics| BC ``` - | Installare sul Server di Gestione | Installare sullo Switch | + | Installare sul server di gestione | Installare sullo switch | |----------------------------------|------------------------| | CLI `doublezero` | Config Agent | - | La tua service keypair | Telemetry Agent | - | La tua metrics publisher keypair | Metrics publisher keypair (copia) | + | Il tuo keypair di servizio | Telemetry Agent | + | Il tuo keypair per la pubblicazione delle metriche | Keypair per la pubblicazione delle metriche (copia) | -### Cosa Sono le Chiavi? +### Cosa sono le chiavi? Pensa alle chiavi come credenziali di accesso sicure: -- **Service Key**: La tua identità come contributore - usata per eseguire i comandi CLI -- **Metrics Publisher Key**: L'identità del tuo dispositivo per l'invio di dati di telemetria +- **Chiave di servizio**: La tua identità come contributore — usata per eseguire i comandi CLI +- **Chiave per la pubblicazione delle metriche**: L'identità del tuo dispositivo per l'invio dei dati di telemetria +- **Chiave per la gestione dei reward**: Controlla quali wallet ricevono i tuoi reward — vedi [Gestione dei Reward](contribute-rewards.md) -Entrambe sono keypair crittografiche (una chiave pubblica che condividi, una chiave privata che mantieni segreta). +Tutte e tre sono coppie di chiavi crittografiche (una chiave pubblica che condividi, una chiave privata che mantieni segreta). ```mermaid flowchart LR subgraph "Your Keys" SK[Service Key
~/.config/solana/id.json] MK[Metrics Publisher Key
~/.config/doublezero/metrics-publisher.json] + RK[Rewards Manager Key
keep offline] end SK -->|Used for| CLI[CLI Commands
doublezero device create
doublezero link create] MK -->|Used for| TEL[Telemetry Agent
Submits metrics onchain] + RK -->|Used for| REW[Rewards Portal
Sets recipient wallets] ``` -### Passo 2.1: Genera la Tua Service Key +!!! note "Tieni la chiave per la gestione dei reward separata" + La chiave di servizio e la chiave per la pubblicazione delle metriche risiedono sul tuo server di gestione e sullo switch. La chiave per la gestione dei reward controlla dove vanno i tuoi fondi, quindi tienila lontana da queste macchine. È necessaria solo quando cambi i tuoi wallet destinatari. + +### Passo 2.1: Generare la chiave di servizio Questa è la tua identità principale per interagire con DoubleZero. @@ -182,29 +229,44 @@ Questa è la tua identità principale per interagire con DoubleZero. doublezero keygen ``` -Questo crea una keypair nella posizione predefinita. L'output mostra la tua **chiave pubblica** - questa è quella che condividerai con DZF. +Questo crea un keypair nella posizione predefinita. L'output mostra la tua **chiave pubblica** — è quella che condividerai con la DZF. -### Passo 2.2: Genera la Tua Metrics Publisher Key +### Passo 2.2: Generare la chiave per la pubblicazione delle metriche -Questa chiave viene utilizzata dal Telemetry Agent per firmare le submission delle metriche. +Questa chiave viene utilizzata dal Telemetry Agent per firmare l'invio delle metriche. ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Passo 2.3: Invia le Chiavi a DZF +### Passo 2.3: Creare il wallet per la gestione dei reward + +Questa è la terza chiave. Controlla quali wallet ricevono i tuoi reward, e non li custodisce mai direttamente. + +Crea un wallet Solana che controlli e con cui puoi firmare, poi finanzialo con circa 0.01 SOL per coprire le commissioni di transazione. Un hardware wallet è una buona scelta. Non riutilizzare la tua chiave di servizio. + +A questo punto hai bisogno solo del wallet. Imposterai i wallet che riceveranno effettivamente i tuoi reward nel [Passo 2.7](#passo-27-impostare-i-destinatari-dei-reward), dopo che la DZF avrà registrato questa chiave. + +### Passo 2.4: Inviare le chiavi alla DZF Contatta la DoubleZero Foundation o Malbec Labs e fornisci: -1. La tua **chiave pubblica della service key** -2. Il tuo **username GitHub** (per l'accesso al repository) +1. La tua **chiave pubblica di servizio** +2. La tua **chiave pubblica per la gestione dei reward** (dal Passo 2.3) +3. Il tuo **username GitHub** (per l'accesso al repository) -Loro provvederanno a: +Inviale tutte e tre insieme. La DZF registra la chiave di servizio e la chiave per la gestione dei reward in transazioni onchain separate, quindi inviarle contemporaneamente risparmia un passaggio. -- Creare il tuo **account contributore** on-chain -- Concedere l'accesso al **repository contributori** privato +!!! danger "Solo chiavi pubbliche" + Non inviare mai una chiave privata o un file keypair a nessuno, inclusa la DZF. La DZF ha bisogno solo delle tue chiavi pubbliche. -### Passo 2.4: Verifica il Tuo Account +Loro faranno: + +- Creare il tuo **account contributore** onchain +- Registrare la tua **chiave per la gestione dei reward** associata alla tua chiave di servizio +- Concedere l'accesso al **repository privato dei contributori** + +### Passo 2.5: Verificare il tuo account Una volta confermato, verifica che il tuo account contributore esista: @@ -212,9 +274,18 @@ Una volta confermato, verifica che il tuo account contributore esista: doublezero contributor list ``` -Dovresti vedere il tuo codice contributore nell'elenco. +Dovresti vedere il tuo codice contributore nella lista. + +Verifica anche che la tua chiave per la gestione dei reward sia stata registrata: -### Passo 2.5: Accedi al Repository Contributori +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` + +La colonna `manager` dovrebbe mostrare la tua chiave pubblica per la gestione dei reward. Se è vuota, chiedi alla DZF di completare quel passaggio. + +### Passo 2.6: Accedere al repository dei contributori Il repository [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contiene: @@ -223,59 +294,90 @@ Il repository [malbeclabs/contributors](https://github.com/malbeclabs/contributo - Configurazioni ACL - Istruzioni di configurazione aggiuntive -Segui le istruzioni lì per la configurazione specifica del dispositivo. +Segui le istruzioni presenti per la configurazione specifica del dispositivo. + +### Passo 2.7: Impostare i destinatari dei reward + +Ora indica quali wallet ricevono i tuoi reward e in quali proporzioni. Fallo prima che il tuo dispositivo inizi a trasportare traffico. I reward si accumulano dal momento in cui i tuoi link sono attivi, ma il protocollo non può erogarli finché non hai nominato i wallet destinatari. + +Accedi a [doublezero.xyz/rewards](https://doublezero.xyz/rewards) con il tuo wallet per la gestione dei reward, seleziona la tua chiave di servizio, poi inserisci ciascun wallet destinatario e la sua percentuale. Le percentuali devono sommare a 100. + +!!! warning "Ogni destinatario necessita di un token account 2Z" + Il protocollo invia 2Z con un semplice trasferimento di token e non crea il token account al posto tuo. Un wallet destinatario senza token account 2Z causa il fallimento del pagamento di quell'epoca. + +Vedi [Gestione dei Reward](contribute-rewards.md) per la guida completa, inclusa l'alternativa tramite CLI, come verificare il token account e come verificare il risultato. --- -## Fase 3: Provisioning del Dispositivo +## Fase 3: Provisioning del dispositivo Ora registrerai il tuo dispositivo fisico sulla blockchain e configurerai le sue interfacce. -### Comprendere i Tipi di Dispositivo +### Comprendere i tipi di dispositivo + +**Edge** — accetta solo connessioni utente ```mermaid -flowchart TB - subgraph "Edge Device" - E[Edge DZD] - EU[Users connect here] - EU --> E - E <-->|DZX Link| ED[Other DZD] +flowchart LR + subgraph EDZD[Edge DZD] + E_CYOA["DIA · CYOA interface"] + E_TUN["Loopback100/101 + (user tunnel endpoint)"] + E_DZX["DZX link interface"] + E_CYOA --- E_TUN end + EU["Users"] -.|GRE tunnel|.-> E_CYOA + E_DZX <-->|DZX Link| ED["DZD (different contributor)"] +``` + +**Transit** — muove il traffico tra dispositivi, nessuna connessione utente - subgraph "Transit Device" - T[Transit DZD] - T <-->|WAN Link| T2[Another DZD] - T <-->|DZX Link| TD[Other DZD] +```mermaid +flowchart LR + subgraph TDZD[Transit DZD] + T_WAN["WAN link interface"] + T_DZX["DZX link interface"] end + T_WAN <-->|WAN Link| T2["DZD (same contributor)"] + T_DZX <-->|DZX Link| TD["DZD (different contributor)"] +``` + +**Hybrid** — connessioni utente e backbone, il più comune - subgraph "Hybrid Device" - H[Hybrid DZD] - HU[Users connect here] - HU --> H - H <-->|WAN Link| H2[Another DZD] - H <-->|DZX Link| HD[Other DZD] +```mermaid +flowchart LR + subgraph HDZD[Hybrid DZD] + H_CYOA["DIA · CYOA interface"] + H_TUN["Loopback100/101 + (user tunnel endpoint)"] + H_WAN["WAN link interface"] + H_DZX["DZX link interface"] + H_CYOA --- H_TUN end + HU["Users"] -.|GRE tunnel|.-> H_CYOA + H_WAN <-->|WAN Link| H2["DZD (same contributor)"] + H_DZX <-->|DZX Link| HD["DZD (different contributor)"] ``` -| Tipo | Cosa Fa | Quando Usarlo | +| Tipo | Cosa fa | Quando usarlo | |------|---------|---------------| | **Edge** | Accetta solo connessioni utente | Singola posizione, solo rivolto agli utenti | -| **Transit** | Sposta il traffico tra dispositivi | Connettività backbone, nessun utente | -| **Hybrid** | Connessioni utente E backbone | Il più comune - fa tutto | +| **Transit** | Muove il traffico tra dispositivi | Connettività backbone, nessun utente | +| **Hybrid** | Sia connessioni utente CHE backbone | Il più comune — fa tutto | -### Passo 3.1: Trova la Tua Posizione e l'Exchange +### Passo 3.1: Trovare la tua posizione e exchange Prima di creare il tuo dispositivo, cerca i codici per la posizione del tuo data center e l'exchange più vicino: ```bash -# List available locations (data centers) +# Elencare le posizioni disponibili (data center) doublezero location list -# List available exchanges (interconnect points) +# Elencare gli exchange disponibili (punti di interconnessione) doublezero exchange list ``` -### Passo 3.2: Crea il Tuo Dispositivo On-Chain +### Passo 3.2: Creare il tuo dispositivo onchain Registra il tuo dispositivo sulla blockchain: @@ -315,43 +417,50 @@ Verifica che il tuo dispositivo sia stato creato: doublezero device list | grep nyc-dz001 ``` -**Parametri spiegati:** +**Spiegazione dei parametri:** -| Parametro | Cosa Significa | -|-----------|----------------| +| Parametro | Significato | +|-----------|-------------| | `--code` | Un nome univoco per il tuo dispositivo (es. `nyc-dz001`) | -| `--contributor` | Il tuo codice contributore (fornito da DZF) | -| `--device-type` | `hybrid`, `transit`, o `edge` | +| `--contributor` | Il tuo codice contributore (fornito dalla DZF) | +| `--device-type` | `hybrid`, `transit` o `edge` | | `--location` | Codice del data center da `location list` | | `--exchange` | Codice dell'exchange più vicino da `exchange list` | -| `--public-ip` | L'IP pubblico dove gli utenti si connettono al tuo dispositivo via internet | +| `--public-ip` | L'IP pubblico tramite cui gli utenti si connettono al tuo dispositivo via internet | | `--dz-prefixes` | Il tuo blocco IP allocato per gli utenti | -### Passo 3.3: Crea le Interfacce Loopback Richieste +### Passo 3.3: Creare le interfacce loopback richieste -Ogni dispositivo ha bisogno di due interfacce loopback per il routing interno: +Ogni dispositivo necessita di due interfacce loopback per il routing interno: ```bash -# VPNv4 loopback +# Loopback VPNv4 doublezero device interface create Loopback255 --loopback-type vpnv4 -# IPv4 loopback +# Loopback IPv4 doublezero device interface create Loopback256 --loopback-type ipv4 ``` -**Output atteso (per ogni comando):** +**Output atteso (per ciascun comando):** ``` Signature: 3mNx9K...truncated...8wRt5 ``` -### Passo 3.4: Crea Interfacce Fisiche +### Passo 3.4: Creare le interfacce fisiche -Registra le porte fisiche che utilizzerai: +Registra le interfacce fisiche che verranno utilizzate per i link WAN o DZX. Queste interfacce devono esistere on-chain prima che tu possa creare un link che le referenzia. In questo passo registri solo l'interfaccia e la sua larghezza di banda; il link viene creato in un passo successivo. ```bash -# Basic interface -doublezero device interface create Ethernet1/1 +doublezero device interface create \ + --bandwidth +``` + +**Esempio:** + +```bash +doublezero device interface create nyc-dz001 Ethernet1/1 \ + --bandwidth 10Gbps ``` **Output atteso:** @@ -360,38 +469,40 @@ doublezero device interface create Ethernet1/1 Signature: 7pQw2R...truncated...4xKm9 ``` -### Passo 3.5: Crea l'Interfaccia CYOA (per dispositivi Edge/Hybrid) +Ripeti per ogni interfaccia che verrà utilizzata come endpoint di un link WAN o DZX. Le interfacce CYOA e DIA vengono registrate separatamente nel passo successivo. + +### Passo 3.5: Creare l'interfaccia CYOA (per dispositivi Edge/Hybrid) -I DZD ibridi e edge necessitano di **due indirizzi IP pubblici** su cui gli utenti terminano i loro tunnel GRE. Gli utenti possono connettersi tramite unicast, multicast, o entrambi, e quale IP serve quale scopo viene ruotato per utente. +I DZD hybrid e edge necessitano di **due indirizzi IP pubblici** su cui gli utenti terminano i loro tunnel GRE. Gli utenti possono connettersi tramite unicast, multicast o entrambi, e quale IP serve quale scopo ruota per ogni utente. -Entrambi gli IP devono essere registrati con `--user-tunnel-endpoint true`, su un'interfaccia fisica o su un loopback. Questo include l'IP fornito al momento della creazione del dispositivo; quell'IP deve ancora essere registrato esplicitamente qui. +Entrambi gli IP devono essere registrati con `--user-tunnel-endpoint true`, su un'interfaccia fisica o un loopback. Questo include l'IP che hai fornito al momento della creazione del dispositivo: quell'IP deve comunque essere registrato esplicitamente qui. -Se sei vincolato da IP, puoi usare il primo `/32` del tuo prefisso DZ come uno dei due IP. +Se hai vincoli di IP, puoi utilizzare il primo `/32` del tuo prefisso DZ come uno dei due IP. #### CYOA e DIA | Tipo | Flag | Scopo | |------|------|-------| -| DIA | `--interface-dia dia` | Marca la porta come accesso internet diretto | -| CYOA | `--interface-cyoa ` | Dichiara come gli utenti connettono tunnel GRE al tuo dispositivo | +| DIA | `--interface-dia dia` | Contrassegna la porta come accesso diretto a internet | +| CYOA | `--interface-cyoa ` | Dichiara come gli utenti connettono i tunnel GRE al tuo dispositivo | -Il flag CYOA è sempre impostato su un'**interfaccia fisica** (porta Ethernet o port channel). Mai su un loopback. +Il flag CYOA viene sempre impostato su un'**interfaccia fisica** (porta Ethernet o port channel). Mai su un loopback. -| Sottotipo CYOA | Quando usare | -|---------------|-------------| +| Sottotipo CYOA | Quando usarlo | +|----------------|---------------| | `gre-over-dia` | Gli utenti si connettono tramite internet pubblico. Il più comune. | -| `gre-over-private-peering` | Gli utenti si connettono tramite cross-connect diretto o circuito privato | -| `gre-over-public-peering` | Gli utenti fanno peering con te a un Internet Exchange (IX) | +| `gre-over-private-peering` | Gli utenti si connettono tramite una cross-connect diretta o un circuito privato | +| `gre-over-public-peering` | Gli utenti fanno peering con te presso un Internet Exchange (IX) | | `gre-over-fabric` | Gli utenti sono co-locati e si connettono tramite un fabric locale | -| `gre-over-cable` | Connessione cavo diretta a un singolo utente dedicato | +| `gre-over-cable` | Connessione diretta via cavo a un singolo utente dedicato | -#### Scenario A: Interfaccia fisica singola +#### Scenario A: Singola interfaccia fisica -Un uplink fisico all'ISP. Ethernet1/1 è l'interfaccia CYOA e DIA e porta uno dei due IP pubblici. Loopback100 porta il secondo IP pubblico. +Un singolo uplink fisico verso l'ISP. Ethernet1/1 è l'interfaccia CYOA e DIA e porta uno dei due IP pubblici. Loopback100 porta il secondo IP pubblico. ```mermaid flowchart LR - USERS(["Utenti Finali"]) + USERS(["End Users"]) subgraph DZD["DZD"] E1["Eth1/1 @@ -402,20 +513,20 @@ flowchart LR E1 --- LO end - ISP["Router ISP + ISP["ISP Router 203.0.113.2/30"] ISP -- "10GbE" --- E1 - USERS -. "Tunnel GRE" .-> E1 - USERS -. "Tunnel GRE" .-> LO + USERS -. "GRE tunnels" .-> E1 + USERS -. "GRE tunnels" .-> LO ``` | Interfaccia | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sottorete assegnata dal contributore | velocità porta | tariffa impegnata | `bgp` o `static` | `true` | -| Loopback100 | — | — | tuo /32 pubblico | `0bps` | — | — | `true` | +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità della porta | tasso garantito | `bgp` o `static` | `true` | +| Loopback100 | — | — | il tuo /32 pubblico | `0bps` | — | — | `true` | -Esempio di comandi per lo Scenario A: +Esempio di comandi da eseguire per lo Scenario A: ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -438,9 +549,9 @@ Il DZD si connette al dispositivo upstream tramite un port channel con un IP. Il ```mermaid flowchart LR - USERS(["Utenti Finali"]) + USERS(["End Users"]) - subgraph SW["Router/Switch Upstream"] + subgraph SW["Upstream Router / Switch"] SWPC(["bond0 203.0.113.2/30"]) end @@ -456,16 +567,16 @@ flowchart LR end SWPC -- "2x 10GbE" --- PC - USERS -. "Tunnel GRE" .-> PC - USERS -. "Tunnel GRE" .-> LO + USERS -. "GRE tunnels" .-> PC + USERS -. "GRE tunnels" .-> LO ``` | Interfaccia | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | IP/sottorete assegnata dal contributore | velocità LAG combinata | tariffa impegnata | `bgp` o `static` | `true` | -| Loopback100 | — | — | tuo /32 pubblico | `0bps` | — | — | `true` | +| Port-Channel1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità LAG combinata | tasso garantito | `bgp` o `static` | `true` | +| Loopback100 | — | — | il tuo /32 pubblico | `0bps` | — | — | `true` | -Esempio di comandi per lo Scenario B: +Esempio di comandi da eseguire per lo Scenario B: ```bash doublezero device interface create mydzd-fra01 Port-Channel1 \ --interface-cyoa gre-over-dia \ @@ -482,13 +593,14 @@ doublezero device interface create mydzd-fra01 Loopback100 \ --user-tunnel-endpoint true ``` -#### Scenario C: Doppi uplink fisici verso router separati -Ogni interfaccia fisica si connette a un router upstream diverso. I due IP pubblici si trovano su Loopback100 e Loopback101, entrambi registrati come endpoint di tunnel utente. +#### Scenario C: Doppio uplink fisico verso router separati + +Ogni interfaccia fisica si connette a un router upstream diverso. I due IP pubblici risiedono su Loopback100 e Loopback101, entrambi registrati come endpoint per i tunnel utente. ```mermaid flowchart LR - USERS(["Utenti Finali"]) + USERS(["End Users"]) RA["Router A 203.0.113.2/30"] @@ -504,509 +616,4 @@ flowchart LR CYOA · DIA"] LO0["Loopback100 198.51.100.1/32\n user tunnel endpoint"] - LO1["Loopback101 - 198.51.100.2/32\n user tunnel endpoint"] - E1 --> LO0 - E2 --> LO1 - end - - RA -- "10GbE" --- E1 - RB -- "10GbE" --- E2 - USERS -. "Tunnel GRE" .-> LO0 - USERS -. "Tunnel GRE" .-> LO1 -``` - -| Interfaccia | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sottorete assegnata dal contributore | velocità porta | tariffa impegnata | `bgp` o `static` | — | -| Ethernet2/1 | `gre-over-dia` | `dia` | IP/sottorete assegnata dal contributore | velocità porta | tariffa impegnata | `bgp` o `static` | — | -| Loopback100 | — | — | tuo /32 pubblico | `0bps` | — | — | `true` | -| Loopback101 | — | — | tuo /32 pubblico | `0bps` | — | — | `true` | - -Esempio di comandi per lo Scenario C: -```bash -doublezero device interface create mydzd-ams01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Ethernet2/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.5/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-ams01 Loopback101 \ - --ip-net 198.51.100.2/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -### Passo 3.6: Verifica il Tuo Dispositivo - -```bash -doublezero device list -``` - -**Output di esempio:** - -``` - account | code | contributor | location | exchange | device_type | public_ip | dz_prefixes | users | max_users | status | health | mgmt_vrf | owner - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -Il tuo dispositivo dovrebbe apparire con stato `activated`. - ---- - -## Fase 4: Stabilimento del Link e Installazione degli Agent - -I link connettono il tuo dispositivo al resto della rete DoubleZero. - -### Comprendere i Link - -```mermaid -flowchart LR - subgraph "Your Network" - D1[Your DZD 1
NYC] - D2[Your DZD 2
LAX] - end - - subgraph "Other Contributor" - O1[Their DZD
NYC] - end - - D1 ---|WAN Link
Same contributor| D2 - D1 ---|DZX Link
Different contributors| O1 -``` - -| Tipo di Link | Connette | Accettazione | -|-------------|---------|--------------| -| **WAN Link** | Due dei TUOI dispositivi | Automatica (possiedi entrambi) | -| **DZX Link** | Il tuo dispositivo a quello di UN ALTRO contributore | Richiede la loro accettazione | - -### Passo 4.1: Crea WAN Link (se hai più dispositivi) - -I WAN link connettono i tuoi dispositivi: - -```bash -doublezero link create wan \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --side-z-interface \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 20 \ - --jitter-ms 1 -``` - -**Esempio:** - -```bash -doublezero link create wan \ - --code nyc-lax-wan01 \ - --contributor acme \ - --side-a nyc-dz001 \ - --side-a-interface Ethernet3/1 \ - --side-z lax-dz001 \ - --side-z-interface Ethernet3/1 \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 65 \ - --jitter-ms 1 -``` - -**Output atteso:** - -``` -Signature: 5tNm7K...truncated...9pRw2 -``` - -### Passo 4.2: Crea DZX Link - -I DZX link connettono il tuo dispositivo direttamente al DZD di un altro contributore: - -```bash -doublezero link create dzx \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --bandwidth \ - --mtu \ - --delay-ms \ - --jitter-ms -``` - -**Output atteso:** - -``` -Signature: 8mKp3W...truncated...2nRx7 -``` - -Dopo aver creato un DZX link, l'altro contributore deve accettarlo: - -```bash -# The OTHER contributor runs this -doublezero link accept \ - --code \ - --side-z-interface -``` - -**Output atteso (per il contributore che accetta):** - -``` -Signature: 6vQt9L...truncated...3wPm4 -``` - -### Passo 4.3: Verifica i Link - -```bash -doublezero link list -``` - -**Output di esempio:** - -``` - account | code | contributor | side_a_name | side_a_iface_name | side_z_name | side_z_iface_name | link_type | bandwidth | mtu | delay_ms | jitter_ms | delay_override_ms | tunnel_id | tunnel_net | status | health | owner - 8vkYpXaBW8RuknJq... | nyc-dz001:lax-dz001 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -I link dovrebbero mostrare lo stato `activated` una volta che entrambi i lati sono configurati. - ---- - -### Installazione degli Agent - -Due software agent vengono eseguiti sul tuo DZD: - -```mermaid -flowchart TB - subgraph "Your DZD" - CA[Config Agent] - TA[Telemetry Agent] - HW[Switch Hardware/Software] - end - - CA -->|Polls for config| CTRL[Controller Service] - CA -->|Applies config| HW - - HW -->|Metrics| TA - TA -->|Submits onchain| BC[DoubleZero Ledger] -``` - -| Agent | Cosa Fa | -|-------|---------| -| **Config Agent** | Recupera la configurazione dal controller, la applica al tuo switch | -| **Telemetry Agent** | Misura latenza/perdita verso altri dispositivi, riporta le metriche on-chain | - -### Passo 4.4: Installa il Config Agent - -#### Abilita l'API sul tuo switch - -Aggiungi alla configurazione EOS: - -``` -management api eos-sdk-rpc - transport grpc eapilocal - localhost loopback vrf default - service all - no disabled -``` - -!!! note "Nota VRF" - Sostituisci `default` con il nome del tuo VRF di gestione se diverso (es. `management`). - -#### Scarica e installa l'agent - -```bash -# Enter bash on the switch -switch# bash -$ sudo bash -# cd /mnt/flash -# wget AGENT_DOWNLOAD_URL -# exit -$ exit - -# Install as EOS extension -switch# copy flash:AGENT_FILENAME extension: -switch# extension AGENT_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Verifica l'estensione - -```bash -switch# show extensions -``` - -Lo stato dovrebbe essere "A, I, B": - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -AGENT_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configura e avvia l'agent - -Aggiungi alla configurazione EOS: - -``` -daemon doublezero-agent - exec /usr/local/bin/doublezero-agent -pubkey - no shut -``` - -!!! note "Nota VRF" - Se il tuo VRF di gestione non è `default` (cioè il namespace non è `ns-default`), anteponi al comando exec `exec /sbin/ip netns exec ns-`. Ad esempio, se il tuo VRF è `management`: - ``` - daemon doublezero-agent - exec /sbin/ip netns exec ns-management /usr/local/bin/doublezero-agent -pubkey - no shut - ``` - -Ottieni la pubkey del tuo dispositivo da `doublezero device list` (la colonna `account`). - -#### Verifica che sia in esecuzione - -```bash -switch# show agent doublezero-agent logs -``` - -Dovresti vedere "Starting doublezero-agent" e connessioni riuscite al controller. - -### Passo 4.5: Installa il Telemetry Agent - -#### Copia la metrics publisher key sul tuo dispositivo - -```bash -scp ~/.config/doublezero/metrics-publisher.json :/mnt/flash/metrics-publisher-keypair.json -``` - -#### Registra il metrics publisher on-chain - -```bash -doublezero device update \ - --pubkey \ - --metrics-publisher -``` - -Ottieni la pubkey dal tuo file metrics-publisher.json. - -#### Scarica e installa l'agent - -```bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget TELEMETRY_DOWNLOAD_URL -# exit -$ exit - -# Install as EOS extension -switch# copy flash:TELEMETRY_FILENAME extension: -switch# extension TELEMETRY_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Verifica l'estensione - -```bash -switch# show extensions -``` - -Lo stato dovrebbe essere "A, I, B": - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -TELEMETRY_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configura e avvia l'agent - -Aggiungi alla configurazione EOS: - -``` -daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut -``` - -!!! note "Nota VRF" - Se il tuo VRF di gestione non è `default` (cioè il namespace non è `ns-default`), aggiungi `--management-namespace ns-` al comando exec. Ad esempio, se il tuo VRF è `management`: - ``` - daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --management-namespace ns-management --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut - ``` - -#### Verifica che sia in esecuzione - -```bash -switch# show agent doublezero-telemetry logs -``` - -Dovresti vedere "Starting telemetry collector" e "Starting submission loop". - ---- - -## Fase 5: Burn-in del Link - -!!! warning "Tutti i nuovi link devono completare il burn-in prima di trasportare traffico" - I nuovi link devono essere **drenati per almeno 24 ore** prima di essere attivati per il traffico di produzione. Questo requisito di burn-in è definito in [RFC12: Network Provisioning](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md), che specifica ~200.000 slot del DZ Ledger (~20 ore) di metriche pulite prima che un link sia pronto per il servizio. - -Con gli agent installati e in esecuzione, monitora i tuoi link su [metrics.doublezero.xyz](https://metrics.doublezero.xyz) per almeno 24 ore consecutive: - -- Dashboard **"DoubleZero Device-Link Latencies"** — verifica **zero perdita di pacchetti** sul link nel tempo -- Dashboard **"DoubleZero Network Metrics"** — verifica **zero errori** sui tuoi link - -Sblocca il link solo quando il periodo di burn-in mostra un link pulito con zero perdite e zero errori. - ---- - -## Fase 6: Verifica e Attivazione - -Esegui questa checklist per confermare che tutto funzioni. - -!!! warning "Il tuo dispositivo inizia bloccato (`max_users = 0`)" - Quando viene creato un dispositivo, `max_users` è impostato a **0** per impostazione predefinita. Ciò significa che nessun utente può ancora connettersi ad esso. Questo è intenzionale — devi verificare che tutto funzioni prima di accettare traffico utente. - - **Prima di impostare `max_users` sopra 0, devi:** - - 1. Confermare che tutti i link abbiano completato il **burn-in di 24 ore** con zero perdite/errori su [metrics.doublezero.xyz](https://metrics.doublezero.xyz) - 2. **Coordinarsi con DZ/Malbec Labs** per eseguire un test di connettività: - - Un utente di test può connettersi al tuo dispositivo? - - L'utente riceve route tramite la rete DZ? - - L'utente può instradare il traffico tramite la rete DZ end-to-end? - 3. Solo dopo che DZ/ML conferma che i test sono passati, imposta max_users a 96: - - ```bash - doublezero device update --pubkey --max-users 96 - ``` - -### Controlli del Dispositivo - -```bash -# Your device should appear with status "activated" -doublezero device list | grep -``` - -**Output atteso:** - -``` - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -```bash -# Your interfaces should be listed -doublezero device interface list | grep -``` - -**Output atteso:** - -``` - nyc-dz001 | Loopback255 | loopback | vpnv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.91/32 | 56 | false | activated - nyc-dz001 | Loopback256 | loopback | ipv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.100/32 | 0 | false | activated - nyc-dz001 | Ethernet1/1 | physical | none | none | none | 0 | 0 | 1500 | static | 0 | | 0 | false | activated -``` - -### Controlli dei Link - -```bash -# Links should show status "activated" -doublezero link list | grep -``` - -**Output atteso:** - -``` - 8vkYpXaBW8RuknJq... | nyc-lax-wan01 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -### Controlli degli Agent - -Sullo switch: - -```bash -# Config agent should show successful config pulls -switch# show agent doublezero-agent logs | tail -20 - -# Telemetry agent should show successful submissions -switch# show agent doublezero-telemetry logs | tail -20 -``` - -### Diagramma di Verifica Finale - -```mermaid -flowchart TB - subgraph "Verification Checklist" - D[Device Status: activated?] - I[Interfaces: registered?] - L[Links: activated?] - CA[Config Agent: pulling config?] - TA[Telemetry Agent: submitting metrics?] - end - - D --> PASS - I --> PASS - L --> PASS - CA --> PASS - TA --> PASS - - PASS[All Checks Pass] --> NOTIFY[Notify DZF/Malbec Labs
You are technically ready!] -``` - ---- - -## Risoluzione dei Problemi - -### Creazione del dispositivo fallisce - -- Verifica che la tua service key sia autorizzata (`doublezero contributor list`) -- Controlla che i codici di posizione e exchange siano validi -- Assicurati che il prefisso DZ sia un intervallo IP pubblico valido - -### Link bloccato nello stato "requested" - -- I DZX link richiedono l'accettazione dall'altro contributore -- Contattali per eseguire `doublezero link accept` - -### Config Agent non si connette - -- Verifica che la rete di gestione abbia accesso a internet -- Controlla che la configurazione VRF corrisponda alla tua configurazione -- Assicurati che la pubkey del dispositivo sia corretta - -### Telemetry Agent non invia - -- Verifica che la metrics publisher key sia registrata on-chain -- Controlla che il file keypair esista sullo switch -- Assicurati che la pubkey dell'account del dispositivo sia corretta - ---- - -## Prossimi Passi - -- Consulta la [Guida Operativa](contribute-operations.md) per gli aggiornamenti degli agent e la gestione dei link -- Consulta il [Glossario](glossary.md) per le definizioni dei termini -- Contatta DZF/Malbec Labs se riscontri problemi + L \ No newline at end of file diff --git a/docs/contribute-provisioning.ja.md b/docs/contribute-provisioning.ja.md index 7649583..ef50d6f 100644 --- a/docs/contribute-provisioning.ja.md +++ b/docs/contribute-provisioning.ja.md @@ -1,151 +1,192 @@ -# デバイスプロビジョニングガイド -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: DoubleZero デバイス（DZD）のプロビジョニングおよびインターフェースとロールのオンチェーン登録に関するステップバイステップガイド。 +--- +# デバイスプロビジョニングガイド -このガイドでは、DoubleZeroデバイス（DZD）を最初から最後までプロビジョニングする手順を説明します。各フェーズは[オンボーディングチェックリスト](contribute-overview.md#onboarding-checklist)に対応しています。 +このガイドでは、DoubleZero デバイス（DZD）のプロビジョニングを最初から最後まで手順を追って説明します。各フェーズは[オンボーディングチェックリスト](contribute-overview.md#onboarding-checklist)に対応しています。 --- -## 全体像 +## 全体の仕組み + +このガイドでは、DoubleZero ネットワークがインフラストラクチャを通じてトラフィックをルーティングできるように、インフラストラクチャをオンチェーンに登録する手順を説明します。デバイスの登録が完全であるほど、ネットワークにとってより有用なものとなります。デバイスの完全なオンチェーン表現により、トラブルシューティング、キャパシティプランニングが改善され、コントローラーが適切な判断を行えるようになります。将来的には、コントローラーがより多くの構成責任を担うことが目標です。 + +### 主要な概念 + +**インターフェース** + +DZD のインターフェースにはさまざまな形態があります：イーサネットポート、ポートチャネル（複数のイーサネットポートで構成される LAG）、ループバックです。ネットワークで役割を持つ各インターフェースは、プロトコルがその役割を認識できるよう、適切なフラグを付けてオンチェーンに登録する必要があります。 + +イーサネットポートとポートチャネルは以下の役割を果たすことができます： + +| フラグ | 意味 | +|------|---------------| +| `--interface-dia dia` | インターフェースをダイレクトインターネットアクセスのアップリンクとしてマーク | +| `--interface-cyoa ` | ユーザーがこのインターフェースを通じて GRE トンネルを確立する方法を宣言（例：パブリックインターネット経由、プライベートピアリングリンク経由） | +| `--user-tunnel-endpoint true` | このインターフェースはユーザーが GRE トンネルを終端するパブリック IP を持つ | -手順に入る前に、構築するものの全体像を確認しましょう： +WAN または DZX リンクに使用されるインターフェースには特定のフラグは付きません。帯域幅とともに登録され、リンク作成時に参照されます。 + +ループバックインターフェースにはいくつかの目的があります： + +| ループバック | 意味 | +|----------|---------------| +| **Loopback100 / 101** | ユーザーが GRE トンネルを終端するパブリック IP を持つ。`--user-tunnel-endpoint true` で登録。 | +| **Loopback255** (`vpnv4`) | コントローラーが BGP ルーター ID、VPN-IPv4 ピアリング（ユニキャスト）、IS-IS アイデンティティ、セグメントルーティングに使用する IP を割り当てられるよう登録 | +| **Loopback256** (`ipv4`) | コントローラーが IPv4 BGP ピアリング（マルチキャスト）および MSDP セッションに使用する IP を割り当てられるよう登録 | + +**リンク** + +リンクはインターフェースとは別に登録され、リンクがインターフェースを参照するには、インターフェースが先にオンチェーンに存在している必要があります。WAN または DZX リンクを作成する際、リンクの物理エンドポイントとして既に登録済みのインターフェースを指定します。すべてのインターフェースがリンクに紐づくわけではありません：DIA、CYOA、ループバックインターフェースはリンクに接続されません。 + +| 用語 | 意味 | +|------|---------------| +| **WAN リンク** | 自分が所有する 2 つの DZD 間のリンク | +| **DZX リンク** | 自分の DZD と他のコントリビューターの DZD 間のリンク | + +### アーキテクチャ概要 ```mermaid flowchart TB subgraph Onchain - SC[DoubleZeroレジャー] + SC[DoubleZero Ledger] end subgraph Your Infrastructure - MGMT[管理サーバー
DoubleZero CLI] - DZD[あなたのDZD
Aristaスイッチ] - DZD ---|WANリンク| DZD2[もう一台のDZD] + MGMT[Management Server
DoubleZero CLI] + subgraph DZD[Your DZD] + CYOA["DIA · CYOA interface
(user-facing uplink)"] + WAN_INTF["WAN link interface"] + DZX_INTF["DZX link interface"] + LO100["Loopback100/101
(user tunnel endpoint)"] + end + DZD2[Your other DZD] end subgraph Other Contributor - OtherDZD[他のDZD] + OtherDZD[Their DZD] end - subgraph Users - VAL[バリデーター] - RPC[RPCノード] - end + USERS["Users"] - MGMT -.->|デバイス、リンク、
インターフェースを登録| SC - DZD ---|DZXリンク| OtherDZD - VAL ---|インターネット経由で接続| DZD - RPC ---|インターネット経由で接続| DZD + MGMT -.->|Registers devices,
links, interfaces| SC + WAN_INTF ---|WAN Link| DZD2 + DZX_INTF ---|DZX Link| OtherDZD + USERS -.|GRE tunnel|.-> CYOA + CYOA ---|routes to| LO100 ``` --- -## フェーズ1：前提条件 +## フェーズ 1：前提条件 -デバイスをプロビジョニングする前に、物理的なハードウェアをセットアップし、いくつかのIPアドレスを割り当てる必要があります。 +デバイスをプロビジョニングする前に、物理ハードウェアのセットアップといくつかの IP アドレスの割り当てが必要です。 ### 必要なもの | 要件 | 必要な理由 | |-------------|-----------------| -| **DZDハードウェア** | Arista 7280CR3Aスイッチ（[ハードウェア仕様](contribute.md#hardware-requirements)参照） | -| **ラックスペース** | 適切なエアフローを持つ4U | -| **電力** | 冗長フィード、約4KW推奨 | -| **管理アクセス** | スイッチを設定するためのSSH/コンソールアクセス | -| **インターネット接続** | メトリクスのパブリッシュとコントローラーからの設定取得のため | -| **パブリックIPv4ブロック** | DZプレフィックスプール用の最小/29（以下参照） | +| **DZD ハードウェア** | Arista 7280CR3A スイッチ（[ハードウェア仕様](contribute.md#hardware-requirements)を参照） | +| **ラックスペース** | DZD あたり 1U、適切なエアフローを確保。[ラック＆電源](contribute.md#rack-power-requirements)を参照 | +| **電源** | 2 系統の独立した電源フィード、各系統が単独で全負荷を賄えること。[ラック＆電源](contribute.md#rack-power-requirements)を参照 | +| **管理アクセス** | スイッチ設定のための SSH/コンソールアクセス | +| **インターネット接続** | メトリクスの公開およびコントローラーからの設定取得用 | +| **パブリック IPv4 ブロック** | DZ プレフィックスプール用に最低 /29（下記参照） | -### DoubleZero CLIのインストール +### DoubleZero CLI のインストール -DoubleZero CLI（`doublezero`）はプロビジョニング全体でデバイスの登録、リンクの作成、貢献の管理に使用されます。DZDスイッチ自体ではなく、**管理サーバーまたはVM**にインストールする必要があります。スイッチはConfig AgentとTelemetry Agentのみを実行します（[フェーズ4](#phase-4-link-establishment-agent-installation)でインストール）。 +DoubleZero CLI（`doublezero`）は、プロビジョニング全体を通じてデバイスの登録、リンクの作成、コントリビューションの管理に使用されます。**管理サーバーまたは VM** にインストールしてください — DZD スイッチ本体にはインストールしないでください。スイッチには Config Agent と Telemetry Agent のみがインストールされます（[フェーズ 4](#phase-4-link-establishment-agent-installation) でインストール）。 -**Ubuntu / Debian：** +**Ubuntu / Debian:** ```bash curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.deb.sh | sudo -E bash sudo apt-get install doublezero ``` -**Rocky Linux / RHEL：** +**Rocky Linux / RHEL:** ```bash curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.rpm.sh | sudo -E bash sudo yum install doublezero ``` -デーモンが実行中であることを確認します： +デーモンが実行中であることを確認： ```bash sudo systemctl status doublezerod ``` -### DZプレフィックスについて +### DZ プレフィックスについて -DZプレフィックスはDoubleZeroプロトコルがIP割り当てに管理するパブリックIPアドレスのブロックです。 +DZ プレフィックスは、DoubleZero プロトコルが IP 割り当てを管理するパブリック IP アドレスのブロックです。 ```mermaid flowchart LR - subgraph "あなたの/29ブロック（8 IP）" - IP1["最初のIP
デバイス用に
予約"] + subgraph "Your /29 Block (8 IPs)" + IP1["First IP
Reserved for
your device"] IP2["IP 2"] IP3["IP 3"] IP4["..."] IP8["IP 8"] end - IP1 -->|割り当て先| LO[DZD上の
Loopback100] - IP2 -->|割り当て先| U1[ユーザー1] - IP3 -->|割り当て先| U2[ユーザー2] + IP1 -->|Assigned to| LO[Loopback100
on your DZD] + IP2 -->|Allocated to| U1[User 1] + IP3 -->|Allocated to| U2[User 2] ``` -**DZプレフィックスの使用方法：** +**DZ プレフィックスの使用方法：** -- **最初のIP**：デバイス用に予約（Loopback100インターフェースに割り当て） -- **残りのIP**：DZDに接続する特定のユーザータイプに割り当て： - - `IBRLWithAllocatedIP`ユーザー - - `EdgeFiltering`ユーザー - - マルチキャストパブリッシャー -- **IBRLユーザー**：このプールを消費しません（独自のパブリックIPを使用） +- **最初の IP**：デバイス用に予約（Loopback100 インターフェースに割り当て） +- **残りの IP**：DZD に接続する特定のユーザータイプに割り当て： + - `IBRLWithAllocatedIP` ユーザー + - `EdgeFiltering` ユーザー（将来のユースケース） +- **IBRL ユーザー**：このプールからは消費しません（独自のパブリック IP を使用） -!!! warning "DZプレフィックスルール" - **これらのアドレスは以下に使用できません：** +!!! warning "DZ プレフィックスのルール" + **これらのアドレスを以下の用途に使用することはできません：** - 自社のネットワーク機器 - - DIAインターフェースのポイントツーポイントリンク + - DIA インターフェースのポイントツーポイントリンク - 管理インターフェース - - DZプロトコル外のインフラ + - DZ プロトコル外のインフラストラクチャ **要件：** - - **グローバルにルーティング可能（パブリック）**なIPv4アドレスである必要があります - - プライベートIP範囲（10.x、172.16-31.x、192.168.x）はスマートコントラクトで拒否されます - - **最小サイズ：/29**（8アドレス）、大きなプレフィックス推奨（例：/28、/27） + - **グローバルにルーティング可能な（パブリック）** IPv4 アドレスである必要があります + - プライベート IP レンジ（10.x、172.16-31.x、192.168.x）はスマートコントラクトにより拒否されます + - **最小サイズ：/29**（8 アドレス）、より大きなプレフィックスが推奨（例：/28、/27） - ブロック全体が利用可能である必要があります — アドレスを事前に割り当てないでください - 自社の機器用にアドレスが必要な場合（DIAインターフェースIP、管理など）は、**別のアドレスプール**を使用してください。 + 自社機器用のアドレス（DIA インターフェース IP、管理用など）が必要な場合は、**別のアドレスプール**を使用してください。 --- -## フェーズ2：アカウントのセットアップ +## フェーズ 2：アカウントセットアップ -このフェーズでは、ネットワーク上でアカウントとデバイスを識別する暗号鍵を作成します。 +このフェーズでは、ネットワーク上であなたとデバイスを識別する暗号鍵を作成し、報酬の送付先を指定します。 -### CLIを実行する場所 +このフェーズでは 3 つの鍵が生成されます：サービスキー、メトリクスパブリッシャーキー、報酬マネージャーキーです。3 つすべての公開鍵を[ステップ 2.4](#step-24-submit-keys-to-dzf) でまとめて DZF に提出してください。[報酬管理](contribute-rewards.md)で報酬に関する詳細を説明しています。 -!!! warning "スイッチにCLIをインストールしないでください" - DoubleZero CLI（`doublezero`）はAristaスイッチではなく、**管理サーバーまたはVM**にインストールする必要があります。 +### CLI の実行場所 + +!!! warning "スイッチに CLI をインストールしないでください" + DoubleZero CLI（`doublezero`）は、Arista スイッチではなく **管理サーバーまたは VM** にインストールしてください。 ```mermaid flowchart LR - subgraph "管理サーバー/VM" + subgraph "Management Server/VM" CLI[DoubleZero CLI] - KEYS[キーペア] + KEYS[Your Keypairs] end - subgraph "DZDスイッチ" + subgraph "Your DZD Switch" CA[Config Agent] TA[Telemetry Agent] end - CLI -->|デバイス、リンクを作成| BC[ブロックチェーン] - CA -->|設定を取得| CTRL[コントローラー] - TA -->|メトリクスを送信| BC + CLI -->|Creates devices, links| BC[Blockchain] + CA -->|Pulls config| CTRL[Controller] + TA -->|Submits metrics| BC ``` | 管理サーバーにインストール | スイッチにインストール | @@ -154,118 +195,179 @@ flowchart LR | サービスキーペア | Telemetry Agent | | メトリクスパブリッシャーキーペア | メトリクスパブリッシャーキーペア（コピー） | -### キーとは？ +### キーとは何か？ -キーは安全なログイン認証情報のようなものです： +キーは安全なログイン資格情報のようなものです： -- **サービスキー**：コントリビューターアイデンティティ - CLIコマンドの実行に使用 -- **メトリクスパブリッシャーキー**：テレメトリデータを送信するためのデバイスアイデンティティ +- **サービスキー**：コントリビューターとしてのアイデンティティ - CLI コマンドの実行に使用 +- **メトリクスパブリッシャーキー**：テレメトリデータ送信時のデバイスのアイデンティティ +- **報酬マネージャーキー**：報酬を受け取るウォレットを制御 - [報酬管理](contribute-rewards.md)を参照 -どちらも暗号鍵ペア（共有する公開鍵と秘密に保持する秘密鍵）です。 +3 つすべてが暗号キーペア（共有する公開鍵と秘密にする秘密鍵）です。 ```mermaid flowchart LR - subgraph "あなたのキー" - SK[サービスキー
~/.config/solana/id.json] - MK[メトリクスパブリッシャーキー
~/.config/doublezero/metrics-publisher.json] + subgraph "Your Keys" + SK[Service Key
~/.config/solana/id.json] + MK[Metrics Publisher Key
~/.config/doublezero/metrics-publisher.json] + RK[Rewards Manager Key
keep offline] end - SK -->|使用先| CLI[CLIコマンド
doublezero device create
doublezero link create] - MK -->|使用先| TEL[Telemetry Agent
メトリクスをオンチェーンに送信] + SK -->|Used for| CLI[CLI Commands
doublezero device create
doublezero link create] + MK -->|Used for| TEL[Telemetry Agent
Submits metrics onchain] + RK -->|Used for| REW[Rewards Portal
Sets recipient wallets] ``` -### ステップ2.1：サービスキーの生成 +!!! note "報酬マネージャーキーは分離して保管してください" + サービスキーとメトリクスパブリッシャーキーは管理サーバーとスイッチに置きます。報酬マネージャーキーはお金の送付先を制御するため、それらのマシンには置かないでください。受取ウォレットを変更するときにのみ必要です。 + +### ステップ 2.1：サービスキーの生成 -これはDoubleZeroと対話するためのメインアイデンティティです。 +これは DoubleZero とのやり取りに使用するメインのアイデンティティです。 ```bash doublezero keygen ``` -これにより、デフォルトの場所にキーペアが作成されます。出力には**公開鍵**が表示されます - これをDZFと共有します。 +デフォルトの場所にキーペアが作成されます。出力には **公開鍵** が表示されます — これが DZF と共有するものです。 -### ステップ2.2：メトリクスパブリッシャーキーの生成 +### ステップ 2.2：メトリクスパブリッシャーキーの生成 -このキーはTelemetry Agentがメトリクス送信に署名するために使用します。 +このキーは Telemetry Agent がメトリクス送信に署名するために使用します。 ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### ステップ2.3：DZFへのキーの提出 +### ステップ 2.3：報酬マネージャーウォレットの作成 -DoubleZero FoundationまたはMalbec Labsに連絡し、以下を提供します： +3 つ目のキーです。報酬を受け取るウォレットを制御しますが、報酬自体を保持しません。 + +自分で管理し署名できる Solana ウォレットを作成し、トランザクション手数料を賄うために約 0.01 SOL をチャージしてください。ハードウェアウォレットが良い選択です。サービスキーを再利用しないでください。 + +この時点ではウォレットだけが必要です。実際に報酬を受け取るウォレットの設定は、DZF がこのキーを登録した後の[ステップ 2.7](#step-27-set-your-reward-recipients) で行います。 + +### ステップ 2.4：DZF へのキー提出 + +DoubleZero Foundation または Malbec Labs に連絡し、以下を提供してください： 1. **サービスキーの公開鍵** -2. **GitHubユーザー名**（リポジトリアクセスのため） +2. **報酬マネージャーの公開鍵**（ステップ 2.3 で作成したもの） +3. **GitHub ユーザー名**（リポジトリアクセス用） + +3 つをまとめて送信してください。DZF はサービスキーと報酬マネージャーキーを別々のオンチェーントランザクションで登録するため、同時に送ることでラウンドトリップを節約できます。 -DZFは以下を行います： +!!! danger "公開鍵のみ" + 秘密鍵やキーペアファイルを DZF を含む誰にも送信しないでください。DZF が必要とするのは公開鍵のみです。 -- **コントリビューターアカウント**をオンチェーンで作成 -- プライベートな**contributorsリポジトリ**へのアクセスを付与 +DZF は以下を行います： -### ステップ2.4：アカウントの確認 +- オンチェーンに **コントリビューターアカウント** を作成 +- サービスキーに対して **報酬マネージャーキー** を登録 +- プライベート **コントリビューターリポジトリ** へのアクセスを付与 -確認後、コントリビューターアカウントが存在することを確認します： +### ステップ 2.5：アカウントの確認 + +確認が取れたら、コントリビューターアカウントが存在することを確認します： ```bash doublezero contributor list ``` -一覧にコントリビューターコードが表示されるはずです。 +リストにあなたのコントリビューターコードが表示されるはずです。 + +報酬マネージャーキーも登録されたか確認します： + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` + +`manager` 列に報酬マネージャーの公開鍵が表示されるはずです。空の場合は、DZF にそのステップの完了を依頼してください。 + +### ステップ 2.6：コントリビューターリポジトリへのアクセス + +[malbeclabs/contributors](https://github.com/malbeclabs/contributors) リポジトリには以下が含まれています： + +- 基本デバイス設定 +- TCAM プロファイル +- ACL 設定 +- 追加のセットアップ手順 + +デバイス固有の設定については、そこの手順に従ってください。 -### ステップ2.5：Contributorsリポジトリへのアクセス +### ステップ 2.7：報酬受取先の設定 -[malbeclabs/contributors](https://github.com/malbeclabs/contributors)リポジトリには以下が含まれています： +報酬を受け取るウォレットとその比率を指定します。デバイスがトラフィックを処理し始める前にこれを行ってください。報酬はリンクが稼働した瞬間から蓄積されますが、受取ウォレットを指定するまでプロトコルは支払いを行えません。 -- ベースデバイス設定 -- TCAMプロファイル -- ACL設定 -- 追加セットアップ手順 +報酬マネージャーウォレットで [doublezero.xyz/rewards](https://doublezero.xyz/rewards) にサインインし、サービスキーを選択してから、各受取ウォレットとそのパーセンテージを入力します。パーセンテージの合計は 100 にする必要があります。 -デバイス固有の設定については、そこの指示に従ってください。 +!!! warning "各受取先には 2Z トークンアカウントが必要です" + プロトコルはプレーントークン転送で 2Z を送信し、トークンアカウントを自動作成しません。2Z トークンアカウントを持たない受取ウォレットは、そのエポックの支払いが失敗する原因となります。 + +CLI による代替手段、トークンアカウントの確認方法、結果の検証方法を含む完全なウォークスルーは[報酬管理](contribute-rewards.md)を参照してください。 --- -## フェーズ3：デバイスプロビジョニング +## フェーズ 3：デバイスプロビジョニング + +ここでは、物理デバイスをブロックチェーンに登録し、インターフェースを設定します。 -ここでは物理的なデバイスをブロックチェーンに登録し、インターフェースを設定します。 +### デバイスタイプの理解 -### デバイスタイプについて +**Edge** — ユーザー接続のみを受け付ける ```mermaid -flowchart TB - subgraph "エッジデバイス" - E[エッジDZD] - EU[ユーザーはここに接続] - EU --> E - E <-->|DZXリンク| ED[他のDZD] +flowchart LR + subgraph EDZD[Edge DZD] + E_CYOA["DIA · CYOA interface"] + E_TUN["Loopback100/101 + (user tunnel endpoint)"] + E_DZX["DZX link interface"] + E_CYOA --- E_TUN end + EU["Users"] -.|GRE tunnel|.-> E_CYOA + E_DZX <-->|DZX Link| ED["DZD (different contributor)"] +``` - subgraph "トランジットデバイス" - T[トランジットDZD] - T <-->|WANリンク| T2[別のDZD] - T <-->|DZXリンク| TD[他のDZD] +**Transit** — デバイス間のトラフィックを転送、ユーザー接続なし + +```mermaid +flowchart LR + subgraph TDZD[Transit DZD] + T_WAN["WAN link interface"] + T_DZX["DZX link interface"] end + T_WAN <-->|WAN Link| T2["DZD (same contributor)"] + T_DZX <-->|DZX Link| TD["DZD (different contributor)"] +``` + +**Hybrid** — ユーザー接続とバックボーンの両方、最も一般的 - subgraph "ハイブリッドデバイス" - H[ハイブリッドDZD] - HU[ユーザーはここに接続] - HU --> H - H <-->|WANリンク| H2[別のDZD] - H <-->|DZXリンク| HD[他のDZD] +```mermaid +flowchart LR + subgraph HDZD[Hybrid DZD] + H_CYOA["DIA · CYOA interface"] + H_TUN["Loopback100/101 + (user tunnel endpoint)"] + H_WAN["WAN link interface"] + H_DZX["DZX link interface"] + H_CYOA --- H_TUN end + HU["Users"] -.|GRE tunnel|.-> H_CYOA + H_WAN <-->|WAN Link| H2["DZD (same contributor)"] + H_DZX <-->|DZX Link| HD["DZD (different contributor)"] ``` -| タイプ | 機能 | 使用するとき | +| タイプ | 役割 | 使用する場面 | |------|--------------|-------------| -| **エッジ** | ユーザー接続のみを受け入れる | 単一ロケーション、ユーザー向けのみ | -| **トランジット** | デバイス間のトラフィックを移動 | バックボーン接続、ユーザーなし | -| **ハイブリッド** | ユーザー接続とバックボーンの両方 | 最も一般的 - すべてを行う | +| **Edge** | ユーザー接続のみを受け付ける | 単一拠点、ユーザー対応のみ | +| **Transit** | デバイス間のトラフィックを転送 | バックボーン接続、ユーザーなし | +| **Hybrid** | ユーザー接続とバックボーンの両方 | 最も一般的 — すべてを担う | -### ステップ3.1：ロケーションとエクスチェンジを調べる +### ステップ 3.1：ロケーションとエクスチェンジの確認 -デバイスを作成する前に、データセンターの場所と最寄りのエクスチェンジのコードを調べます： +デバイスを作成する前に、データセンターのロケーションと最寄りのエクスチェンジのコードを調べます： ```bash # 利用可能なロケーション（データセンター）を一覧表示 @@ -275,19 +377,19 @@ doublezero location list doublezero exchange list ``` -### ステップ3.2：デバイスをオンチェーンで作成する +### ステップ 3.2：デバイスのオンチェーン作成 -ブロックチェーンにデバイスを登録します： +デバイスをブロックチェーンに登録します： ```bash doublezero device create \ - --code <デバイスコード> \ - --contributor <コントリビューターコード> \ + --code \ + --contributor \ --device-type hybrid \ - --location <ロケーションコード> \ - --exchange <エクスチェンジコード> \ - --public-ip <デバイスパブリックIP> \ - --dz-prefixes + --location \ + --exchange \ + --public-ip \ + --dz-prefixes ``` **例：** @@ -315,28 +417,28 @@ Signature: 4vKz8H...truncated...7xPq2 doublezero device list | grep nyc-dz001 ``` -**パラメーターの説明：** +**パラメータの説明：** -| パラメーター | 意味 | +| パラメータ | 意味 | |-----------|---------------| -| `--code` | デバイスの一意の名前（例：`nyc-dz001`） | -| `--contributor` | コントリビューターコード（DZFから付与） | -| `--device-type` | `hybrid`、`transit`、または`edge` | -| `--location` | `location list`からのデータセンターコード | -| `--exchange` | `exchange list`からの最寄りエクスチェンジコード | -| `--public-ip` | ユーザーがインターネット経由でデバイスに接続するパブリックIP | -| `--dz-prefixes` | ユーザー用の割り当てIPブロック | +| `--code` | デバイスの一意な名前（例：`nyc-dz001`） | +| `--contributor` | コントリビューターコード（DZF より付与） | +| `--device-type` | `hybrid`、`transit`、または `edge` | +| `--location` | `location list` から取得したデータセンターコード | +| `--exchange` | `exchange list` から取得した最寄りのエクスチェンジコード | +| `--public-ip` | ユーザーがインターネット経由でデバイスに接続するパブリック IP | +| `--dz-prefixes` | ユーザー用に割り当てられた IP ブロック | -### ステップ3.3：必要なループバックインターフェースを作成する +### ステップ 3.3：必要なループバックインターフェースの作成 -すべてのデバイスには内部ルーティング用の2つのループバックインターフェースが必要です： +すべてのデバイスには内部ルーティング用に 2 つのループバックインターフェースが必要です： ```bash -# VPNv4ループバック -doublezero device interface create <デバイスコード> Loopback255 --loopback-type vpnv4 +# VPNv4 ループバック +doublezero device interface create Loopback255 --loopback-type vpnv4 -# IPv4ループバック -doublezero device interface create <デバイスコード> Loopback256 --loopback-type ipv4 +# IPv4 ループバック +doublezero device interface create Loopback256 --loopback-type ipv4 ``` **期待される出力（各コマンド）：** @@ -345,13 +447,20 @@ doublezero device interface create <デバイスコード> Loopback256 --loopbac Signature: 3mNx9K...truncated...8wRt5 ``` -### ステップ3.4：物理インターフェースを作成する +### ステップ 3.4：物理インターフェースの作成 + +WAN または DZX リンクに使用される物理インターフェースを登録します。これらのインターフェースは、リンクが参照する前にオンチェーンに存在している必要があります。このステップではインターフェースと帯域幅のみを登録し、リンクは後のステップで作成します。 + +```bash +doublezero device interface create \ + --bandwidth +``` -使用する物理ポートを登録します： +**例：** ```bash -# 基本インターフェース -doublezero device interface create <デバイスコード> Ethernet1/1 +doublezero device interface create nyc-dz001 Ethernet1/1 \ + --bandwidth 10Gbps ``` **期待される出力：** @@ -360,38 +469,40 @@ doublezero device interface create <デバイスコード> Ethernet1/1 Signature: 7pQw2R...truncated...4xKm9 ``` -### ステップ3.5：CYOAインターフェースを作成する（エッジ/ハイブリッドデバイスの場合） +WAN または DZX リンクのエンドポイントとして使用する各インターフェースについてこれを繰り返します。CYOA および DIA インターフェースは次のステップで別途登録します。 + +### ステップ 3.5：CYOA インターフェースの作成（Edge/Hybrid デバイス用） -ハイブリッドおよびエッジDZDには、ユーザーがGREトンネルを終端する**2つのパブリックIPアドレス**が必要です。ユーザーはユニキャスト、マルチキャスト、またはその両方で接続でき、どのIPがどの目的に使用されるかはユーザーごとにローテーションされます。 +Hybrid および Edge の DZD では、ユーザーが GRE トンネルを終端する **2 つのパブリック IP アドレス** が必要です。ユーザーはユニキャスト、マルチキャスト、またはその両方で接続でき、どの IP がどの目的に使われるかはユーザーごとにローテーションします。 -両方のIPは、物理インターフェースまたはループバックのいずれかで`--user-tunnel-endpoint true`で登録する必要があります。これには、デバイス作成時に指定したIPも含まれます。そのIPもここで明示的に登録する必要があります。 +両方の IP を `--user-tunnel-endpoint true` で、物理インターフェースまたはループバックに登録する必要があります。これにはデバイス作成時に指定した IP も含まれます — その IP もここで明示的に登録する必要があります。 -IP制約がある場合は、DZプレフィックスの最初の`/32`を2つのIPの1つとして使用できます。 +IP が不足している場合は、DZ プレフィックスの最初の `/32` を 2 つの IP の 1 つとして使用できます。 -#### CYOAとDIA +#### CYOA と DIA | タイプ | フラグ | 目的 | -|--------|--------|------| +|------|------|---------| | DIA | `--interface-dia dia` | ポートをダイレクトインターネットアクセスとしてマーク | -| CYOA | `--interface-cyoa <サブタイプ>` | ユーザーがデバイスにGREトンネルを接続する方法を宣言 | +| CYOA | `--interface-cyoa ` | ユーザーがデバイスに GRE トンネルを接続する方法を宣言 | -CYOAフラグは常に**物理インターフェース**（イーサネットポートまたはポートチャネル）に設定されます。ループバックには設定しません。 +CYOA フラグは常に **物理インターフェース**（イーサネットポートまたはポートチャネル）に設定します。ループバックには設定しません。 -| CYOAサブタイプ | 使用場面 | -|--------------|---------| +| CYOA サブタイプ | 使用する場面 | +|-------------|-------------| | `gre-over-dia` | ユーザーがパブリックインターネット経由で接続。最も一般的。 | -| `gre-over-private-peering` | ユーザーが直接クロスコネクトまたはプライベート回線で接続 | +| `gre-over-private-peering` | ユーザーがダイレクトクロスコネクトまたはプライベート回線経由で接続 | | `gre-over-public-peering` | ユーザーがインターネットエクスチェンジ（IX）でピアリング | -| `gre-over-fabric` | ユーザーが同一施設内にありローカルファブリックで接続 | +| `gre-over-fabric` | ユーザーが同一拠点にいてローカルファブリック経由で接続 | | `gre-over-cable` | 単一の専用ユーザーへの直接ケーブル接続 | -#### シナリオA：単一物理インターフェース +#### シナリオ A：単一物理インターフェース -ISPへの1つの物理アップリンク。Ethernet1/1はCYOAおよびDIAインターフェースで、2つのパブリックIPのうちの1つを持ちます。Loopback100が2番目のパブリックIPを持ちます。 +ISP への物理アップリンクが 1 本。Ethernet1/1 が CYOA および DIA インターフェースで、2 つのパブリック IP の 1 つを持ちます。Loopback100 が 2 つ目のパブリック IP を持ちます。 ```mermaid flowchart LR - USERS(["エンドユーザー"]) + USERS(["End Users"]) subgraph DZD["DZD"] E1["Eth1/1 @@ -402,611 +513,7 @@ flowchart LR E1 --- LO end - ISP["ISPルーター - 203.0.113.2/30"] - - ISP -- "10GbE" --- E1 - USERS -. "GREトンネル" .-> E1 - USERS -. "GREトンネル" .-> LO -``` - -| インターフェース | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|----------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | コントリビューター割当IP/サブネット | ポート速度 | コミットレート | `bgp`または`static` | `true` | -| Loopback100 | — | — | パブリック/32 | `0bps` | — | — | `true` | - -シナリオAに基づくコマンド例： -```bash -doublezero device interface create mydzd-nyc01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-nyc01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -#### シナリオB：ポートチャネル（LAG） - -DZDがIPを持つポートチャネルでアップストリームデバイスに接続します。ポートチャネルが1つのパブリックIPを持ち、CYOAエンドポイントになります。Loopback100が2番目のパブリックIPを持ちます。 - -```mermaid -flowchart LR - USERS(["エンドユーザー"]) - - subgraph SW["アップストリームルーター/スイッチ"] - SWPC(["bond0 - 203.0.113.2/30"]) - end - - subgraph DZD["DZD"] - subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · user tunnel endpoint"] - E1["Eth1/1"] - E2["Eth2/1"] - end - LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - PC --- LO - end - - SWPC -- "2x 10GbE" --- PC - USERS -. "GREトンネル" .-> PC - USERS -. "GREトンネル" .-> LO -``` - -| インターフェース | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|----------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | コントリビューター割当IP/サブネット | 組み合わせLAG速度 | コミットレート | `bgp`または`static` | `true` | -| Loopback100 | — | — | パブリック/32 | `0bps` | — | — | `true` | - -シナリオBに基づくコマンド例： -```bash -doublezero device interface create mydzd-fra01 Port-Channel1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 20Gbps \ - --cir 2Gbps \ - --routing-mode bgp \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-fra01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -#### シナリオC：別々のルーターへのデュアル物理アップリンク - -各物理インターフェースが異なるアップストリームルーターに接続します。2つのパブリックIPはLoopback100とLoopback101に存在し、両方ともユーザートンネルエンドポイントとして登録されます。 - -```mermaid -flowchart LR - USERS(["エンドユーザー"]) - - RA["ルーターA + ISP["ISP Router 203.0.113.2/30"] - RB["ルーターB - 203.0.113.6/30"] - - subgraph DZD["DZD"] - E1["Eth1/1 - 203.0.113.1/30 - CYOA · DIA"] - E2["Eth2/1 - 203.0.113.5/30 - CYOA · DIA"] - LO0["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - LO1["Loopback101 - 198.51.100.2/32\n user tunnel endpoint"] - E1 --> LO0 - E2 --> LO1 - end - - RA -- "10GbE" --- E1 - RB -- "10GbE" --- E2 - USERS -. "GREトンネル" .-> LO0 - USERS -. "GREトンネル" .-> LO1 -``` - -| インターフェース | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|----------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | コントリビューター割当IP/サブネット | ポート速度 | コミットレート | `bgp`または`static` | — | -| Ethernet2/1 | `gre-over-dia` | `dia` | コントリビューター割当IP/サブネット | ポート速度 | コミットレート | `bgp`または`static` | — | -| Loopback100 | — | — | パブリック/32 | `0bps` | — | — | `true` | -| Loopback101 | — | — | パブリック/32 | `0bps` | — | — | `true` | - -シナリオCに基づくコマンド例： -```bash -doublezero device interface create mydzd-ams01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Ethernet2/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.5/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-ams01 Loopback101 \ - --ip-net 198.51.100.2/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -### ステップ3.6：デバイスを確認する - -```bash -doublezero device list -``` - -**出力例：** - -``` - account | code | contributor | location | exchange | device_type | public_ip | dz_prefixes | users | max_users | status | health | mgmt_vrf | owner - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -デバイスはステータス`activated`で表示されるはずです。 - ---- - -## フェーズ4：リンク確立とエージェントインストール - -リンクはデバイスをDoubleZeroネットワークの残りの部分に接続します。 - -### リンクについて - -```mermaid -flowchart LR - subgraph "あなたのネットワーク" - D1[あなたのDZD 1
NYC] - D2[あなたのDZD 2
LAX] - end - - subgraph "他のコントリビューター" - O1[彼らのDZD
NYC] - end - - D1 ---|WANリンク
同一コントリビューター| D2 - D1 ---|DZXリンク
異なるコントリビューター| O1 -``` - -| リンクタイプ | 接続先 | 承認 | -|-----------|----------|------------| -| **WANリンク** | あなたの2つのデバイス | 自動（両方を所有） | -| **DZXリンク** | あなたのデバイスと別のコントリビューターのデバイス | 相手の承認が必要 | - -### ステップ4.1：WANリンクを作成する（複数のデバイスがある場合） - -WANリンクは自分のデバイスを接続します： - -```bash -doublezero link create wan \ - --code <リンクコード> \ - --contributor <コントリビューター> \ - --side-a <デバイス1のコード> \ - --side-a-interface <デバイス1のインターフェース> \ - --side-z <デバイス2のコード> \ - --side-z-interface <デバイス2のインターフェース> \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 20 \ - --jitter-ms 1 -``` - -**例：** - -```bash -doublezero link create wan \ - --code nyc-lax-wan01 \ - --contributor acme \ - --side-a nyc-dz001 \ - --side-a-interface Ethernet3/1 \ - --side-z lax-dz001 \ - --side-z-interface Ethernet3/1 \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 65 \ - --jitter-ms 1 -``` - -**期待される出力：** - -``` -Signature: 5tNm7K...truncated...9pRw2 -``` - -### ステップ4.2：DZXリンクを作成する - -DZXリンクはデバイスを別のコントリビューターのDZDに直接接続します： - -```bash -doublezero link create dzx \ - --code <デバイスコードA:デバイスコードZ> \ - --contributor <コントリビューター> \ - --side-a <あなたのデバイスコード> \ - --side-a-interface <あなたのインターフェース> \ - --side-z <他のデバイスコード> \ - --bandwidth <帯域幅 Kbps、Mbps、またはGbps> \ - --mtu \ - --delay-ms <遅延> \ - --jitter-ms <ジッター> -``` - -**期待される出力：** - -``` -Signature: 8mKp3W...truncated...2nRx7 -``` - -DZXリンクを作成した後、他のコントリビューターがそれを承認する必要があります： - -```bash -# 他のコントリビューターがこれを実行する -doublezero link accept \ - --code <リンクコード> \ - --side-z-interface <彼らのインターフェース> -``` - -**期待される出力（承認するコントリビューター用）：** - -``` -Signature: 6vQt9L...truncated...3wPm4 -``` - -### ステップ4.3：リンクを確認する - -```bash -doublezero link list -``` - -**出力例：** - -``` - account | code | contributor | side_a_name | side_a_iface_name | side_z_name | side_z_iface_name | link_type | bandwidth | mtu | delay_ms | jitter_ms | delay_override_ms | tunnel_id | tunnel_net | status | health | owner - 8vkYpXaBW8RuknJq... | nyc-dz001:lax-dz001 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -両側が設定されるとリンクはステータス`activated`を表示するはずです。 - ---- - -### エージェントのインストール - -2つのソフトウェアエージェントがDZDで実行されます： - -```mermaid -flowchart TB - subgraph "あなたのDZD" - CA[Config Agent] - TA[Telemetry Agent] - HW[スイッチハードウェア/ソフトウェア] - end - - CA -->|設定をポーリング| CTRL[コントローラーサービス] - CA -->|設定を適用| HW - - HW -->|メトリクス| TA - TA -->|オンチェーンに送信| BC[DoubleZeroレジャー] -``` - -| エージェント | 機能 | -|-------|--------------| -| **Config Agent** | コントローラーから設定を取得し、スイッチに適用する | -| **Telemetry Agent** | 他のデバイスへのレイテンシ/ロスを測定し、メトリクスをオンチェーンに報告する | - -### ステップ4.4：Config Agentのインストール - -#### スイッチでAPIを有効にする - -EOS設定に追加します： - -``` -management api eos-sdk-rpc - transport grpc eapilocal - localhost loopback vrf default - service all - no disabled -``` - -!!! note "VRFに関する注意" - 異なる場合（例：`management`）は`default`を管理VRF名に置き換えてください。 - -#### エージェントのダウンロードとインストール - -```bash -# スイッチでbashに入る -switch# bash -$ sudo bash -# cd /mnt/flash -# wget AGENT_DOWNLOAD_URL -# exit -$ exit - -# EOS拡張機能としてインストール -switch# copy flash:AGENT_FILENAME extension: -switch# extension AGENT_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### 拡張機能を確認する - -```bash -switch# show extensions -``` - -ステータスは"A, I, B"であるべきです： - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -AGENT_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### エージェントを設定して起動する - -EOS設定に追加します： - -``` -daemon doublezero-agent - exec /usr/local/bin/doublezero-agent -pubkey <デバイス公開鍵> - no shut -``` - -!!! note "VRFに関する注意" - 管理VRFが`default`でない場合（つまり名前空間が`ns-default`でない場合）、execコマンドに`exec /sbin/ip netns exec ns-`をプレフィックスします。例えば、VRFが`management`の場合： - ``` - daemon doublezero-agent - exec /sbin/ip netns exec ns-management /usr/local/bin/doublezero-agent -pubkey <デバイス公開鍵> - no shut - ``` - -デバイスの公開鍵は`doublezero device list`（`account`列）から取得します。 - -#### 実行中であることを確認する - -```bash -switch# show agent doublezero-agent logs -``` - -"Starting doublezero-agent"とコントローラー接続の成功が表示されるはずです。 - -### ステップ4.5：Telemetry Agentのインストール - -#### メトリクスパブリッシャーキーをデバイスにコピーする - -```bash -scp ~/.config/doublezero/metrics-publisher.json <スイッチIP>:/mnt/flash/metrics-publisher-keypair.json -``` - -#### メトリクスパブリッシャーをオンチェーンに登録する - -```bash -doublezero device update \ - --pubkey <デバイスアカウント> \ - --metrics-publisher <メトリクスパブリッシャー公開鍵> -``` - -公開鍵はmetrics-publisher.jsonファイルから取得します。 - -#### エージェントのダウンロードとインストール - -```bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget TELEMETRY_DOWNLOAD_URL -# exit -$ exit - -# EOS拡張機能としてインストール -switch# copy flash:TELEMETRY_FILENAME extension: -switch# extension TELEMETRY_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### 拡張機能を確認する - -```bash -switch# show extensions -``` - -ステータスは"A, I, B"であるべきです： - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -TELEMETRY_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### エージェントを設定して起動する - -EOS設定に追加します： - -``` -daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --local-device-pubkey <デバイスアカウント> --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut -``` - -!!! note "VRFに関する注意" - 管理VRFが`default`でない場合（つまり名前空間が`ns-default`でない場合）、execコマンドに`--management-namespace ns-`を追加します。例えば、VRFが`management`の場合： - ``` - daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --management-namespace ns-management --local-device-pubkey <デバイスアカウント> --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut - ``` - -#### 実行中であることを確認する - -```bash -switch# show agent doublezero-telemetry logs -``` - -"Starting telemetry collector"と"Starting submission loop"が表示されるはずです。 - ---- - -## フェーズ5：リンクのバーンイン - -!!! warning "すべての新しいリンクはトラフィックを運ぶ前にバーンインする必要があります" - 新しいリンクは本番トラフィックのためにアクティベートされる前に、**少なくとも24時間ドレインする必要があります**。このバーンイン要件は[RFC12: Network Provisioning](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md)で定義されており、リンクがサービス準備完了になる前に約200,000 DZ Ledgerスロット（約20時間）のクリーンなメトリクスが必要です。 - -エージェントがインストールされて実行中になったら、少なくとも24時間連続して[metrics.doublezero.xyz](https://metrics.doublezero.xyz)でリンクを監視します： - -- **"DoubleZero Device-Link Latencies"**ダッシュボード — 時間経過によるリンクの**ゼロパケットロス**を確認 -- **"DoubleZero Network Metrics"**ダッシュボード — リンクの**ゼロエラー**を確認 - -バーンイン期間がゼロロスとゼロエラーのクリーンなリンクを示した後にのみ、リンクのドレインを解除してください。 - ---- - -## フェーズ6：確認とアクティベーション - -すべてが機能していることを確認するために、このチェックリストを実行します。 - -!!! warning "デバイスはロック状態（`max_users = 0`）で開始します" - デバイスが作成されると、`max_users`はデフォルトで**0**に設定されます。これはまだユーザーが接続できないことを意味します。これは意図的なものです — ユーザートラフィックを受け入れる前にすべてが機能していることを確認する必要があります。 - - **`max_users`を0以上に設定する前に、以下を実行する必要があります：** - - 1. すべてのリンクが[metrics.doublezero.xyz](https://metrics.doublezero.xyz)でゼロロス/エラーの**24時間バーンイン**を完了したことを確認 - 2. **DZ/Malbec Labsと協力**して接続テストを実行： - - テストユーザーはデバイスに接続できますか？ - - ユーザーはDZネットワーク上でルートを受信しますか？ - - ユーザーはDZネットワークエンドツーエンドでトラフィックをルーティングできますか？ - 3. DZ/MLがテスト合格を確認した後にのみ、max_usersを96に設定します： - - ```bash - doublezero device update --pubkey <デバイスアカウント> --max-users 96 - ``` - -### デバイスの確認 - -```bash -# デバイスはステータス"activated"で表示されるべき -doublezero device list | grep <デバイスコード> -``` - -**期待される出力：** - -``` - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -```bash -# インターフェースが一覧表示されるべき -doublezero device interface list | grep <デバイスコード> -``` - -**期待される出力：** - -``` - nyc-dz001 | Loopback255 | loopback | vpnv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.91/32 | 56 | false | activated - nyc-dz001 | Loopback256 | loopback | ipv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.100/32 | 0 | false | activated - nyc-dz001 | Ethernet1/1 | physical | none | none | none | 0 | 0 | 1500 | static | 0 | | 0 | false | activated -``` - -### リンクの確認 - -```bash -# リンクはステータス"activated"を表示するべき -doublezero link list | grep <デバイスコード> -``` - -**期待される出力：** - -``` - 8vkYpXaBW8RuknJq... | nyc-lax-wan01 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -### エージェントの確認 - -スイッチ上で： - -```bash -# Config Agentは設定プルの成功を表示するべき -switch# show agent doublezero-agent logs | tail -20 - -# Telemetry Agentは送信の成功を表示するべき -switch# show agent doublezero-telemetry logs | tail -20 -``` - -### 最終確認図 - -```mermaid -flowchart TB - subgraph "確認チェックリスト" - D[デバイスステータス: activated?] - I[インターフェース: 登録済み?] - L[リンク: activated?] - CA[Config Agent: 設定を取得中?] - TA[Telemetry Agent: メトリクスを送信中?] - end - - D --> PASS - I --> PASS - L --> PASS - CA --> PASS - TA --> PASS - - PASS[すべての確認に合格] --> NOTIFY[DZF/Malbec Labsに通知
技術的に準備完了です！] -``` - ---- - -## トラブルシューティング - -### デバイス作成に失敗する - -- サービスキーが承認されていることを確認（`doublezero contributor list`） -- ロケーションとエクスチェンジコードが有効であることを確認 -- DZプレフィックスが有効なパブリックIP範囲であることを確認 - -### リンクが"requested"ステータスから動かない - -- DZXリンクは他のコントリビューターの承認が必要 -- `doublezero link accept`を実行するよう連絡する - -### Config Agentが接続しない - -- 管理ネットワークがインターネットアクセスを持っていることを確認 -- VRF設定がセットアップに一致していることを確認 -- デバイスの公開鍵が正しいことを確認 - -### Telemetry Agentが送信しない - -- メトリクスパブリッシャーキーがオンチェーンに登録されていることを確認 -- キーペアファイルがスイッチに存在することを確認 -- デバイスアカウントの公開鍵が正しいことを確認 - ---- - -## 次のステップ -- エージェントのアップグレードとリンク管理については[オペレーションガイド](contribute-operations.md)を確認する -- 用語の定義については[用語集](glossary.md)を確認する -- 問題が発生した場合はDZF/Malbec Labsに連絡する + ISP \ No newline at end of file diff --git a/docs/contribute-provisioning.ko.md b/docs/contribute-provisioning.ko.md index 1731377..cd10150 100644 --- a/docs/contribute-provisioning.ko.md +++ b/docs/contribute-provisioning.ko.md @@ -1,62 +1,102 @@ -# 장치 프로비저닝 가이드 -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: DoubleZero 디바이스(DZD)를 프로비저닝하고 인터페이스 및 역할을 온체인에 등록하는 단계별 가이드. +--- +# 디바이스 프로비저닝 가이드 -이 가이드는 처음부터 끝까지 DoubleZero 장치(DZD) 프로비저닝을 안내합니다. 각 단계는 [온보딩 체크리스트](contribute-overview.md#onboarding-checklist)와 일치합니다. +이 가이드는 DoubleZero 디바이스(DZD)를 처음부터 끝까지 프로비저닝하는 과정을 안내합니다. 각 단계는 [온보딩 체크리스트](contribute-overview.md#onboarding-checklist)에 대응됩니다. --- -## 전체 구성 이해 +## 전체 구성 개요 + +이 가이드는 DoubleZero 네트워크가 트래픽을 라우팅할 수 있도록 인프라를 온체인에 등록하는 과정을 안내합니다. 디바이스가 더 완전하게 등록될수록 네트워크에 더 유용합니다. 디바이스의 완전한 온체인 표현은 더 나은 문제 해결, 용량 계획을 가능하게 하며 컨트롤러가 정보에 기반한 결정을 내릴 수 있도록 합니다. 시간이 지남에 따라 컨트롤러가 더 많은 구성 책임을 맡는 것이 목표입니다. + +### 핵심 개념 + +**인터페이스** + +DZD의 인터페이스는 다양한 형태로 제공됩니다: 이더넷 포트, 포트 채널(여러 이더넷 포트로 구성된 LAG), 그리고 루프백. 네트워크에서 역할을 수행하는 각 인터페이스는 프로토콜이 그 기능을 알 수 있도록 적절한 플래그와 함께 온체인에 등록되어야 합니다. + +이더넷 포트와 포트 채널은 다음과 같은 역할을 수행할 수 있습니다: + +| 플래그 | 의미 | +|------|---------------| +| `--interface-dia dia` | 인터페이스를 직접 인터넷 접속(DIA) 업링크로 표시 | +| `--interface-cyoa ` | 사용자가 이 인터페이스를 통해 GRE 터널을 설정하는 방법을 선언 (예: 공용 인터넷을 통해, 프라이빗 피어링 링크를 통해) | +| `--user-tunnel-endpoint true` | 이 인터페이스는 사용자가 GRE 터널을 종단하는 공용 IP를 보유 | + +WAN 또는 DZX 링크에 사용되는 인터페이스는 특정 플래그를 갖지 않으며, 대역폭과 함께 등록된 후 링크 생성 시 참조됩니다. + +루프백 인터페이스는 여러 용도로 사용됩니다: -단계를 시작하기 전에 구축하는 것의 큰 그림을 살펴봅니다: +| 루프백 | 의미 | +|----------|---------------| +| **Loopback100 / 101** | 사용자가 GRE 터널을 종단하는 공용 IP를 보유. `--user-tunnel-endpoint true`로 등록. | +| **Loopback255** (`vpnv4`) | 컨트롤러가 BGP 라우터 ID, VPN-IPv4 피어링(유니캐스트), IS-IS 아이덴티티, 세그먼트 라우팅에 사용되는 IP를 할당할 수 있도록 등록 | +| **Loopback256** (`ipv4`) | 컨트롤러가 IPv4 BGP 피어링(멀티캐스트) 및 MSDP 세션에 사용되는 IP를 할당할 수 있도록 등록 | + +**링크** + +링크는 인터페이스와 별도로 등록되며, 링크가 참조하려면 인터페이스가 먼저 온체인에 존재해야 합니다. WAN 또는 DZX 링크를 생성할 때 이미 등록된 인터페이스를 링크의 물리적 엔드포인트로 지정합니다. 모든 인터페이스가 링크에 연결되는 것은 아닙니다: DIA, CYOA, 루프백 인터페이스는 링크에 연결되지 않습니다. + +| 용어 | 의미 | +|------|---------------| +| **WAN 링크** | 자체 DZD 두 대 간의 링크 | +| **DZX 링크** | 자체 DZD와 다른 기여자의 DZD 간의 링크 | + +### 아키텍처 개요 ```mermaid flowchart TB subgraph Onchain - SC[DoubleZero 레저] + SC[DoubleZero 원장] end subgraph Your Infrastructure MGMT[관리 서버
DoubleZero CLI] - DZD[귀하의 DZD
Arista 스위치] - DZD ---|WAN 링크| DZD2[귀하의 다른 DZD] + subgraph DZD[자체 DZD] + CYOA["DIA · CYOA 인터페이스
(사용자 대면 업링크)"] + WAN_INTF["WAN 링크 인터페이스"] + DZX_INTF["DZX 링크 인터페이스"] + LO100["Loopback100/101
(사용자 터널 엔드포인트)"] + end + DZD2[자체 다른 DZD] end subgraph Other Contributor - OtherDZD[상대방 DZD] + OtherDZD[타 기여자의 DZD] end - subgraph Users - VAL[검증자] - RPC[RPC 노드] - end + USERS["사용자"] - MGMT -.->|장치,
링크, 인터페이스 등록| SC - DZD ---|DZX 링크| OtherDZD - VAL ---|인터넷을 통해 연결| DZD - RPC ---|인터넷을 통해 연결| DZD + MGMT -.->|디바이스, 링크,
인터페이스 등록| SC + WAN_INTF ---|WAN 링크| DZD2 + DZX_INTF ---|DZX 링크| OtherDZD + USERS -.|GRE 터널|.-> CYOA + CYOA ---|라우팅 대상| LO100 ``` --- -## 1단계: 사전 요구사항 +## 1단계: 사전 준비 -장치를 프로비저닝하기 전에 물리적 하드웨어 설정과 일부 IP 주소 할당이 필요합니다. +디바이스를 프로비저닝하기 전에 물리적 하드웨어 설정과 일부 IP 주소 할당이 필요합니다. -### 필요한 사항 +### 필요 사항 -| 요구사항 | 필요한 이유 | +| 요구사항 | 필요 이유 | |-------------|-----------------| | **DZD 하드웨어** | Arista 7280CR3A 스위치 ([하드웨어 사양](contribute.md#hardware-requirements) 참조) | -| **랙 공간** | 적절한 공기 흐름을 갖춘 4U | -| **전원** | 이중 피드, ~4KW 권장 | -| **관리 액세스** | 스위치 구성을 위한 SSH/콘솔 액세스 | -| **인터넷 연결** | 메트릭 발행 및 컨트롤러에서 구성 가져오기 | -| **공개 IPv4 블록** | DZ 프리픽스 풀을 위한 최소 /29 (아래 참조) | +| **랙 공간** | DZD당 1U, 적절한 공기 흐름 필요. [랙 & 전원](contribute.md#rack-power-requirements) 참조 | +| **전원** | 각각이 전체 부하를 단독으로 감당할 수 있는 두 개의 독립적인 전원 공급. [랙 & 전원](contribute.md#rack-power-requirements) 참조 | +| **관리 접근** | 스위치 구성을 위한 SSH/콘솔 접근 | +| **인터넷 연결** | 메트릭 발행 및 컨트롤러로부터 구성 가져오기용 | +| **공용 IPv4 블록** | DZ 프리픽스 풀을 위한 최소 /29 (아래 참조) | ### DoubleZero CLI 설치 -DoubleZero CLI(`doublezero`)는 프로비저닝 전반에 걸쳐 장치 등록, 링크 생성 및 기여 관리에 사용됩니다. DZD 스위치가 아닌 **관리 서버 또는 VM**에 설치해야 합니다. 스위치는 Config Agent와 Telemetry Agent([4단계](#phase-4-link-establishment-agent-installation)에서 설치됨)만 실행합니다. +DoubleZero CLI(`doublezero`)는 프로비저닝 전반에 걸쳐 디바이스 등록, 링크 생성 및 기여 관리에 사용됩니다. **관리 서버 또는 VM**에 설치해야 합니다 — DZD 스위치 자체에는 설치하지 마세요. 스위치에는 Config Agent와 Telemetry Agent만 실행됩니다([4단계](#phase-4-link-establishment-agent-installation)에서 설치). **Ubuntu / Debian:** ```bash @@ -70,61 +110,62 @@ curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.rpm.sh | sudo yum install doublezero ``` -데몬이 실행 중인지 확인합니다: +데몬이 실행 중인지 확인: ```bash sudo systemctl status doublezerod ``` -### DZ 프리픽스 이해 +### DZ 프리픽스 이해하기 -DZ 프리픽스는 DoubleZero 프로토콜이 IP 할당을 위해 관리하는 공개 IP 주소 블록입니다. +DZ 프리픽스는 DoubleZero 프로토콜이 IP 할당을 위해 관리하는 공용 IP 주소 블록입니다. ```mermaid flowchart LR - subgraph "귀하의 /29 블록 (8개 IP)" - IP1["첫 번째 IP
장치용
예약됨"] + subgraph "자체 /29 블록 (8개 IP)" + IP1["첫 번째 IP
디바이스용
예약"] IP2["IP 2"] IP3["IP 3"] IP4["..."] IP8["IP 8"] end - IP1 -->|할당됨| LO[귀하의 DZD의
Loopback100] - IP2 -->|할당됨| U1[사용자 1] - IP3 -->|할당됨| U2[사용자 2] + IP1 -->|할당 대상| LO[Loopback100
자체 DZD] + IP2 -->|할당 대상| U1[사용자 1] + IP3 -->|할당 대상| U2[사용자 2] ``` **DZ 프리픽스 사용 방법:** -- **첫 번째 IP**: 장치용으로 예약됨 (Loopback100 인터페이스에 할당) -- **나머지 IP**: DZD에 연결하는 특정 유형의 사용자에게 할당됨: +- **첫 번째 IP**: 디바이스용 예약 (Loopback100 인터페이스에 할당) +- **나머지 IP**: DZD에 연결하는 특정 사용자 유형에 할당: - `IBRLWithAllocatedIP` 사용자 - - `EdgeFiltering` 사용자 - - 멀티캐스트 발행자 -- **IBRL 사용자**: 이 풀을 소비하지 않음 (자신의 공개 IP 사용) + - `EdgeFiltering` 사용자 (향후 사용 사례) +- **IBRL 사용자**: 이 풀에서 소비하지 않음 (자체 공용 IP 사용) !!! warning "DZ 프리픽스 규칙" - **다음 용도로 사용할 수 없습니다:** + **이 주소를 다음 용도로 사용할 수 없습니다:** - - 자신의 네트워크 장비 - - DIA 인터페이스의 점대점 링크 + - 자체 네트워크 장비 + - DIA 인터페이스의 포인트-투-포인트 링크 - 관리 인터페이스 - DZ 프로토콜 외부의 모든 인프라 **요구사항:** - - **전 세계적으로 라우팅 가능한(공개)** IPv4 주소여야 합니다 - - 사설 IP 범위(10.x, 172.16-31.x, 192.168.x)는 스마트 계약에서 거부됩니다 + - **전역적으로 라우팅 가능한 (공용)** IPv4 주소여야 함 + - 사설 IP 범위 (10.x, 172.16-31.x, 192.168.x)는 스마트 컨트랙트에서 거부됨 - **최소 크기: /29** (8개 주소), 더 큰 프리픽스 권장 (예: /28, /27) - - 전체 블록이 사용 가능해야 합니다 — 어떤 주소도 사전 할당하지 마세요 + - 전체 블록이 사용 가능해야 함 — 주소를 미리 할당하지 마세요 - 자신의 장비(DIA 인터페이스 IP, 관리 등)를 위한 주소가 필요한 경우 **별도의 주소 풀**을 사용하세요. + 자체 장비(DIA 인터페이스 IP, 관리 등)에 주소가 필요한 경우 **별도의 주소 풀**을 사용하세요. --- ## 2단계: 계정 설정 -이 단계에서는 네트워크에서 귀하와 장치를 식별하는 암호화 키를 생성합니다. +이 단계에서는 네트워크에서 자신과 디바이스를 식별하는 암호화 키를 생성하고, 보상이 지급될 곳을 지정합니다. + +이 단계에서 세 개의 키가 생성됩니다: 서비스 키, 메트릭 퍼블리셔 키, 보상 관리자 키. 세 개 모두의 공개 키를 [Step 2.4](#step-24-submit-keys-to-dzf)에서 DZF에 함께 제출합니다. [보상 관리](contribute-rewards.md)에서 보상 측면을 자세히 다룹니다. ### CLI 실행 위치 @@ -135,15 +176,15 @@ flowchart LR flowchart LR subgraph "관리 서버/VM" CLI[DoubleZero CLI] - KEYS[귀하의 키쌍] + KEYS[키 쌍] end - subgraph "귀하의 DZD 스위치" + subgraph "자체 DZD 스위치" CA[Config Agent] TA[Telemetry Agent] end - CLI -->|장치, 링크 생성| BC[블록체인] + CLI -->|디바이스, 링크 생성| BC[블록체인] CA -->|구성 가져오기| CTRL[컨트롤러] TA -->|메트릭 제출| BC ``` @@ -151,133 +192,194 @@ flowchart LR | 관리 서버에 설치 | 스위치에 설치 | |-----------------------------|-------------------| | `doublezero` CLI | Config Agent | - | 서비스 키쌍 | Telemetry Agent | - | 메트릭 발행자 키쌍 | 메트릭 발행자 키쌍 (복사) | + | 서비스 키 쌍 | Telemetry Agent | + | 메트릭 퍼블리셔 키 쌍 | 메트릭 퍼블리셔 키 쌍 (복사본) | ### 키란 무엇인가? 키를 안전한 로그인 자격 증명으로 생각하세요: -- **서비스 키**: 기여자 신원 - CLI 명령 실행에 사용 -- **메트릭 발행자 키**: 텔레메트리 데이터 제출을 위한 장치 신원 +- **서비스 키**: 기여자 아이덴티티 - CLI 명령 실행에 사용 +- **메트릭 퍼블리셔 키**: 텔레메트리 데이터 제출을 위한 디바이스 아이덴티티 +- **보상 관리자 키**: 보상을 받을 지갑을 제어 - [보상 관리](contribute-rewards.md) 참조 -둘 다 암호화 키쌍입니다(공유하는 공개 키와 비밀로 유지하는 개인 키). +세 가지 모두 암호화 키 쌍(공유하는 공개 키와 비밀로 유지하는 개인 키)입니다. ```mermaid flowchart LR - subgraph "귀하의 키" + subgraph "키 목록" SK[서비스 키
~/.config/solana/id.json] - MK[메트릭 발행자 키
~/.config/doublezero/metrics-publisher.json] + MK[메트릭 퍼블리셔 키
~/.config/doublezero/metrics-publisher.json] + RK[보상 관리자 키
오프라인 보관] end - SK -->|사용됨| CLI[CLI 명령
doublezero device create
doublezero link create] - MK -->|사용됨| TEL[Telemetry Agent
온체인 메트릭 제출] + SK -->|사용 용도| CLI[CLI 명령
doublezero device create
doublezero link create] + MK -->|사용 용도| TEL[Telemetry Agent
메트릭을 온체인에 제출] + RK -->|사용 용도| REW[보상 포털
수신 지갑 설정] ``` -### 2.1단계: 서비스 키 생성 +!!! note "보상 관리자 키를 별도로 보관하세요" + 서비스 키와 메트릭 퍼블리셔 키는 관리 서버와 스위치에 저장됩니다. 보상 관리자 키는 자금이 전송되는 곳을 제어하므로 해당 머신에서 분리하여 보관하세요. 수신 지갑을 변경할 때만 필요합니다. + +### Step 2.1: 서비스 키 생성 -이것이 DoubleZero와 상호 작용하기 위한 주요 신원입니다. +DoubleZero와 상호작용하기 위한 기본 아이덴티티입니다. ```bash doublezero keygen ``` -이는 기본 위치에 키쌍을 생성합니다. 출력은 **공개 키**를 보여줍니다 — 이것이 DZF와 공유할 것입니다. +기본 위치에 키 쌍이 생성됩니다. 출력에 **공개 키**가 표시됩니다 - 이것이 DZF와 공유할 키입니다. -### 2.2단계: 메트릭 발행자 키 생성 +### Step 2.2: 메트릭 퍼블리셔 키 생성 -이 키는 Telemetry Agent가 메트릭 제출에 서명하는 데 사용됩니다. +이 키는 Telemetry Agent가 메트릭 제출에 서명할 때 사용됩니다. ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### 2.3단계: DZF에 키 제출 +### Step 2.3: 보상 관리자 지갑 생성 + +세 번째 키입니다. 보상을 받을 지갑을 제어하며, 보상 자체를 보유하지는 않습니다. + +자신이 통제하고 서명할 수 있는 Solana 지갑을 생성한 후, 트랜잭션 수수료를 위해 약 0.01 SOL을 충전합니다. 하드웨어 지갑이 좋은 선택입니다. 서비스 키를 재사용하지 마세요. + +이 시점에서는 지갑만 필요합니다. 실제로 보상을 받을 지갑은 DZF가 이 키를 등록한 후 [Step 2.7](#step-27-set-your-reward-recipients)에서 설정합니다. + +### Step 2.4: DZF에 키 제출 DoubleZero Foundation 또는 Malbec Labs에 연락하여 다음을 제공합니다: 1. **서비스 키 공개 키** -2. **GitHub 사용자 이름** (저장소 액세스용) +2. **보상 관리자 공개 키** (Step 2.3에서 생성) +3. **GitHub 사용자명** (저장소 접근용) + +세 가지를 함께 전송합니다. DZF는 서비스 키와 보상 관리자 키를 별도의 온체인 트랜잭션으로 등록하므로, 동시에 보내면 왕복 시간을 절약할 수 있습니다. -그들은: +!!! danger "공개 키만 제출" + DZF를 포함하여 누구에게도 개인 키나 키 쌍 파일을 절대 보내지 마세요. DZF는 공개 키만 필요합니다. -- 온체인에서 **기여자 계정**을 생성합니다 -- 비공개 **기여자 저장소**에 대한 액세스를 부여합니다 +DZF는 다음을 수행합니다: -### 2.4단계: 계정 확인 +- 온체인에 **기여자 계정** 생성 +- 서비스 키에 대해 **보상 관리자 키** 등록 +- 프라이빗 **기여자 저장소**에 대한 접근 권한 부여 -확인이 완료되면 기여자 계정이 존재하는지 확인합니다: +### Step 2.5: 계정 확인 + +확인을 받은 후 기여자 계정이 존재하는지 확인합니다: ```bash doublezero contributor list ``` -목록에 기여자 코드가 표시되어야 합니다. +목록에서 기여자 코드가 표시되어야 합니다. + +보상 관리자 키도 등록되었는지 확인합니다: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` + +`manager` 열에 보상 관리자 공개 키가 표시되어야 합니다. 비어 있으면 DZF에 해당 단계를 완료하도록 요청하세요. -### 2.5단계: 기여자 저장소 액세스 +### Step 2.6: 기여자 저장소 접근 -[malbeclabs/contributors](https://github.com/malbeclabs/contributors) 저장소에는 다음이 포함됩니다: +[malbeclabs/contributors](https://github.com/malbeclabs/contributors) 저장소에는 다음이 포함되어 있습니다: -- 기본 장치 구성 -- TCAM 프로필 +- 기본 디바이스 구성 +- TCAM 프로파일 - ACL 구성 - 추가 설정 지침 -장치별 구성을 위해 해당 지침을 따르세요. +디바이스별 구성에 대해서는 해당 저장소의 지침을 따르세요. + +### Step 2.7: 보상 수신자 설정 + +보상을 받을 지갑과 비율을 지정합니다. 디바이스가 트래픽을 전달하기 전에 이 작업을 수행하세요. 보상은 링크가 활성화되는 순간부터 쌓이지만, 수신 지갑을 지정할 때까지 프로토콜이 보상을 지급할 수 없습니다. + +보상 관리자 지갑으로 [doublezero.xyz/rewards](https://doublezero.xyz/rewards)에 로그인하고, 서비스 키를 선택한 다음, 각 수신 지갑과 비율을 입력합니다. 비율의 합계는 100이어야 합니다. + +!!! warning "각 수신자에게 2Z 토큰 계정이 필요합니다" + 프로토콜은 일반 토큰 전송으로 2Z를 보내며 토큰 계정을 대신 생성하지 않습니다. 2Z 토큰 계정이 없는 수신 지갑은 해당 에포크의 지급 실패를 초래합니다. + +CLI 대안, 토큰 계정 확인 방법, 결과 검증을 포함한 전체 안내는 [보상 관리](contribute-rewards.md)를 참조하세요. --- -## 3단계: 장치 프로비저닝 +## 3단계: 디바이스 프로비저닝 + +이제 물리적 디바이스를 블록체인에 등록하고 인터페이스를 구성합니다. -이제 블록체인에 물리적 장치를 등록하고 인터페이스를 구성합니다. +### 디바이스 유형 이해하기 -### 장치 유형 이해 +**Edge** — 사용자 연결만 수용 ```mermaid -flowchart TB - subgraph "엣지 장치" - E[엣지 DZD] - EU[사용자가 여기에 연결] - EU --> E - E <-->|DZX 링크| ED[다른 DZD] +flowchart LR + subgraph EDZD[Edge DZD] + E_CYOA["DIA · CYOA 인터페이스"] + E_TUN["Loopback100/101 + (사용자 터널 엔드포인트)"] + E_DZX["DZX 링크 인터페이스"] + E_CYOA --- E_TUN end + EU["사용자"] -.|GRE 터널|.-> E_CYOA + E_DZX <-->|DZX 링크| ED["DZD (다른 기여자)"] +``` + +**Transit** — 디바이스 간 트래픽 전달, 사용자 연결 없음 - subgraph "트랜짓 장치" - T[트랜짓 DZD] - T <-->|WAN 링크| T2[다른 DZD] - T <-->|DZX 링크| TD[다른 DZD] +```mermaid +flowchart LR + subgraph TDZD[Transit DZD] + T_WAN["WAN 링크 인터페이스"] + T_DZX["DZX 링크 인터페이스"] end + T_WAN <-->|WAN 링크| T2["DZD (동일 기여자)"] + T_DZX <-->|DZX 링크| TD["DZD (다른 기여자)"] +``` - subgraph "하이브리드 장치" - H[하이브리드 DZD] - HU[사용자가 여기에 연결] - HU --> H - H <-->|WAN 링크| H2[다른 DZD] - H <-->|DZX 링크| HD[다른 DZD] +**Hybrid** — 사용자 연결과 백본 모두, 가장 일반적 + +```mermaid +flowchart LR + subgraph HDZD[Hybrid DZD] + H_CYOA["DIA · CYOA 인터페이스"] + H_TUN["Loopback100/101 + (사용자 터널 엔드포인트)"] + H_WAN["WAN 링크 인터페이스"] + H_DZX["DZX 링크 인터페이스"] + H_CYOA --- H_TUN end + HU["사용자"] -.|GRE 터널|.-> H_CYOA + H_WAN <-->|WAN 링크| H2["DZD (동일 기여자)"] + H_DZX <-->|DZX 링크| HD["DZD (다른 기여자)"] ``` -| 유형 | 기능 | 사용 시기 | +| 유형 | 역할 | 사용 시기 | |------|--------------|-------------| -| **엣지** | 사용자 연결만 허용 | 단일 위치, 사용자 대면만 | -| **트랜짓** | 장치 간 트래픽 이동 | 백본 연결, 사용자 없음 | -| **하이브리드** | 사용자 연결 및 백본 모두 | 가장 일반적 - 모든 것 수행 | +| **Edge** | 사용자 연결만 수용 | 단일 위치, 사용자 대면 전용 | +| **Transit** | 디바이스 간 트래픽 전달 | 백본 연결, 사용자 없음 | +| **Hybrid** | 사용자 연결과 백본 모두 | 가장 일반적 - 모든 기능 수행 | -### 3.1단계: 위치 및 Exchange 찾기 +### Step 3.1: 위치 및 익스체인지 조회 -장치를 생성하기 전에 데이터 센터 위치와 가장 가까운 exchange의 코드를 조회합니다: +디바이스를 생성하기 전에 데이터 센터 위치와 가장 가까운 익스체인지의 코드를 조회합니다: ```bash -# 사용 가능한 위치(데이터 센터) 목록 +# 사용 가능한 위치 (데이터 센터) 목록 doublezero location list -# 사용 가능한 exchange(상호 연결 지점) 목록 +# 사용 가능한 익스체인지 (상호연결 지점) 목록 doublezero exchange list ``` -### 3.2단계: 온체인에서 장치 생성 +### Step 3.2: 디바이스를 온체인에 생성 -블록체인에 장치를 등록합니다: +블록체인에 디바이스를 등록합니다: ```bash doublezero device create \ @@ -309,27 +411,27 @@ doublezero device create \ Signature: 4vKz8H...truncated...7xPq2 ``` -장치가 생성되었는지 확인합니다: +디바이스가 생성되었는지 확인합니다: ```bash doublezero device list | grep nyc-dz001 ``` -**파라미터 설명:** +**매개변수 설명:** -| 파라미터 | 의미 | +| 매개변수 | 의미 | |-----------|---------------| -| `--code` | 장치의 고유 이름 (예: `nyc-dz001`) | -| `--contributor` | 기여자 코드 (DZF가 제공) | -| `--device-type` | `hybrid`, `transit` 또는 `edge` | -| `--location` | `location list`의 데이터 센터 코드 | -| `--exchange` | `exchange list`의 가장 가까운 exchange 코드 | -| `--public-ip` | 사용자가 인터넷을 통해 장치에 연결하는 공개 IP | +| `--code` | 디바이스의 고유 이름 (예: `nyc-dz001`) | +| `--contributor` | 기여자 코드 (DZF에서 제공) | +| `--device-type` | `hybrid`, `transit`, 또는 `edge` | +| `--location` | `location list`에서 확인한 데이터 센터 코드 | +| `--exchange` | `exchange list`에서 확인한 가장 가까운 익스체인지 코드 | +| `--public-ip` | 사용자가 인터넷을 통해 디바이스에 연결하는 공용 IP | | `--dz-prefixes` | 사용자를 위해 할당된 IP 블록 | -### 3.3단계: 필요한 루프백 인터페이스 생성 +### Step 3.3: 필수 루프백 인터페이스 생성 -모든 장치에는 내부 라우팅을 위해 두 개의 루프백 인터페이스가 필요합니다: +모든 디바이스에는 내부 라우팅을 위한 두 개의 루프백 인터페이스가 필요합니다: ```bash # VPNv4 루프백 @@ -339,674 +441,36 @@ doublezero device interface create Loopback255 --loopback-type vpn doublezero device interface create Loopback256 --loopback-type ipv4 ``` -**예상 출력 (각 명령):** +**예상 출력 (각 명령에 대해):** ``` Signature: 3mNx9K...truncated...8wRt5 ``` -### 3.4단계: 물리적 인터페이스 생성 - -사용할 물리적 포트를 등록합니다: - -```bash -# 기본 인터페이스 -doublezero device interface create Ethernet1/1 -``` - -**예상 출력:** - -``` -Signature: 7pQw2R...truncated...4xKm9 -``` - -### 3.5단계: CYOA 인터페이스 생성 (엣지/하이브리드 장치의 경우) - -하이브리드 및 엣지 DZD에는 사용자가 GRE 터널을 종료하는 **두 개의 공개 IP 주소**가 필요합니다. 사용자는 유니캐스트, 멀티캐스트 또는 둘 다를 통해 연결할 수 있으며, 어떤 IP가 어떤 목적으로 사용되는지는 사용자별로 순환됩니다. - -두 IP 모두 물리적 인터페이스 또는 루프백에서 `--user-tunnel-endpoint true`로 등록해야 합니다. 이는 장치 생성 시 제공한 IP도 포함되며, 해당 IP도 여기서 명시적으로 등록해야 합니다. - -IP가 부족한 경우 DZ 프리픽스의 첫 번째 `/32`를 두 IP 중 하나로 사용할 수 있습니다. - -#### CYOA 및 DIA - -| 유형 | 플래그 | 목적 | -|------|--------|------| -| DIA | `--interface-dia dia` | 포트를 직접 인터넷 접근으로 표시 | -| CYOA | `--interface-cyoa <서브타입>` | 사용자가 장치에 GRE 터널을 연결하는 방법 선언 | - -CYOA 플래그는 항상 **물리적 인터페이스**(이더넷 포트 또는 포트 채널)에 설정됩니다. 루프백에는 절대 설정하지 않습니다. - -| CYOA 서브타입 | 사용 시기 | -|-------------|----------| -| `gre-over-dia` | 사용자가 공개 인터넷을 통해 연결. 가장 일반적. | -| `gre-over-private-peering` | 사용자가 직접 크로스 커넥트 또는 전용 회선으로 연결 | -| `gre-over-public-peering` | 사용자가 인터넷 익스체인지(IX)에서 피어링 | -| `gre-over-fabric` | 사용자가 공동 배치되어 로컬 패브릭을 통해 연결 | -| `gre-over-cable` | 단일 전용 사용자에 대한 직접 케이블 연결 | - -#### 시나리오 A: 단일 물리적 인터페이스 - -ISP로의 물리적 업링크 하나. Ethernet1/1이 CYOA 및 DIA 인터페이스이며 두 공개 IP 중 하나를 가집니다. Loopback100이 두 번째 공개 IP를 가집니다. - -```mermaid -flowchart LR - USERS(["최종 사용자"]) - - subgraph DZD["DZD"] - E1["Eth1/1 - 203.0.113.1/30 - CYOA · DIA · user tunnel endpoint"] - LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - E1 --- LO - end - - ISP["ISP 라우터 - 203.0.113.2/30"] - - ISP -- "10GbE" --- E1 - USERS -. "GRE 터널" .-> E1 - USERS -. "GRE 터널" .-> LO -``` - -| 인터페이스 | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | 기여자 할당 IP/서브넷 | 포트 속도 | 약정 속도 | `bgp` 또는 `static` | `true` | -| Loopback100 | — | — | 공개 /32 | `0bps` | — | — | `true` | - -시나리오 A 기반 명령 예시: -```bash -doublezero device interface create mydzd-nyc01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-nyc01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -#### 시나리오 B: 포트 채널 (LAG) +### Step 3.4: 물리적 인터페이스 생성 -DZD가 IP가 있는 포트 채널을 통해 업스트림 장치에 연결됩니다. 포트 채널이 공개 IP 하나를 가지며 CYOA 엔드포인트입니다. Loopback100이 두 번째 공개 IP를 가집니다. +WAN 또는 DZX 링크에 사용될 물리적 인터페이스를 등록합니다. 이 인터페이스는 링크가 참조하려면 먼저 온체인에 존재해야 합니다. 이 단계에서는 인터페이스와 대역폭만 등록하며, 링크는 이후 단계에서 생성됩니다. -```mermaid -flowchart LR - USERS(["최종 사용자"]) - - subgraph SW["업스트림 라우터/스위치"] - SWPC(["bond0 - 203.0.113.2/30"]) - end - - subgraph DZD["DZD"] - subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · user tunnel endpoint"] - E1["Eth1/1"] - E2["Eth2/1"] - end - LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - PC --- LO - end - - SWPC -- "2x 10GbE" --- PC - USERS -. "GRE 터널" .-> PC - USERS -. "GRE 터널" .-> LO -``` - -| 인터페이스 | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | 기여자 할당 IP/서브넷 | 결합 LAG 속도 | 약정 속도 | `bgp` 또는 `static` | `true` | -| Loopback100 | — | — | 공개 /32 | `0bps` | — | — | `true` | - -시나리오 B 기반 명령 예시: ```bash -doublezero device interface create mydzd-fra01 Port-Channel1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 20Gbps \ - --cir 2Gbps \ - --routing-mode bgp \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-fra01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -#### 시나리오 C: 별도 라우터로의 이중 물리적 업링크 - -각 물리적 인터페이스가 다른 업스트림 라우터에 연결됩니다. 두 공개 IP는 Loopback100과 Loopback101에 있으며, 모두 사용자 터널 엔드포인트로 등록됩니다. - -```mermaid -flowchart LR - USERS(["최종 사용자"]) - - RA["라우터 A - 203.0.113.2/30"] - RB["라우터 B - 203.0.113.6/30"] - - subgraph DZD["DZD"] - E1["Eth1/1 - 203.0.113.1/30 - CYOA · DIA"] - E2["Eth2/1 - 203.0.113.5/30 - CYOA · DIA"] - LO0["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - LO1["Loopback101 - 198.51.100.2/32\n user tunnel endpoint"] - E1 --> LO0 - E2 --> LO1 - end - - RA -- "10GbE" --- E1 - RB -- "10GbE" --- E2 - USERS -. "GRE 터널" .-> LO0 - USERS -. "GRE 터널" .-> LO1 -``` - -| 인터페이스 | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | 기여자 할당 IP/서브넷 | 포트 속도 | 약정 속도 | `bgp` 또는 `static` | — | -| Ethernet2/1 | `gre-over-dia` | `dia` | 기여자 할당 IP/서브넷 | 포트 속도 | 약정 속도 | `bgp` 또는 `static` | — | -| Loopback100 | — | — | 공개 /32 | `0bps` | — | — | `true` | -| Loopback101 | — | — | 공개 /32 | `0bps` | — | — | `true` | - -시나리오 C 기반 명령 예시: -```bash -doublezero device interface create mydzd-ams01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Ethernet2/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.5/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-ams01 Loopback101 \ - --ip-net 198.51.100.2/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -### 3.6단계: 장치 확인 - -```bash -doublezero device list -``` - -**예시 출력:** - -``` - account | code | contributor | location | exchange | device_type | public_ip | dz_prefixes | users | max_users | status | health | mgmt_vrf | owner - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -장치가 `activated` 상태로 표시되어야 합니다. - ---- - -## 4단계: 링크 설정 및 에이전트 설치 - -링크는 장치를 나머지 DoubleZero 네트워크에 연결합니다. - -### 링크 이해 - -```mermaid -flowchart LR - subgraph "귀하의 네트워크" - D1[귀하의 DZD 1
NYC] - D2[귀하의 DZD 2
LAX] - end - - subgraph "다른 기여자" - O1[상대방 DZD
NYC] - end - - D1 ---|WAN 링크
동일 기여자| D2 - D1 ---|DZX 링크
다른 기여자| O1 -``` - -| 링크 유형 | 연결 | 수락 | -|-----------|----------|------------| -| **WAN 링크** | 귀하의 두 장치 | 자동 (둘 다 소유) | -| **DZX 링크** | 귀하의 장치 대 다른 기여자 | 상대방 수락 필요 | - -### 4.1단계: WAN 링크 생성 (여러 장치가 있는 경우) - -WAN 링크는 귀하의 자체 장치를 연결합니다: - -```bash -doublezero link create wan \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --side-z-interface \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 20 \ - --jitter-ms 1 +doublezero device interface create \ + --bandwidth ``` **예시:** ```bash -doublezero link create wan \ - --code nyc-lax-wan01 \ - --contributor acme \ - --side-a nyc-dz001 \ - --side-a-interface Ethernet3/1 \ - --side-z lax-dz001 \ - --side-z-interface Ethernet3/1 \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 65 \ - --jitter-ms 1 -``` - -**예상 출력:** - -``` -Signature: 5tNm7K...truncated...9pRw2 -``` - -### 4.2단계: DZX 링크 생성 - -DZX 링크는 장치를 다른 기여자의 DZD에 직접 연결합니다: - -```bash -doublezero link create dzx \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --bandwidth \ - --mtu \ - --delay-ms \ - --jitter-ms +doublezero device interface create nyc-dz001 Ethernet1/1 \ + --bandwidth 10Gbps ``` **예상 출력:** ``` -Signature: 8mKp3W...truncated...2nRx7 -``` - -DZX 링크를 생성한 후 다른 기여자가 이를 수락해야 합니다: - -```bash -# 다른 기여자가 이것을 실행합니다 -doublezero link accept \ - --code \ - --side-z-interface -``` - -**예상 출력 (수락하는 기여자):** - -``` -Signature: 6vQt9L...truncated...3wPm4 -``` - -### 4.3단계: 링크 확인 - -```bash -doublezero link list -``` - -**예시 출력:** - -``` - account | code | contributor | side_a_name | side_a_iface_name | side_z_name | side_z_iface_name | link_type | bandwidth | mtu | delay_ms | jitter_ms | delay_override_ms | tunnel_id | tunnel_net | status | health | owner - 8vkYpXaBW8RuknJq... | nyc-dz001:lax-dz001 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -양쪽이 구성되면 링크는 `activated` 상태를 표시해야 합니다. - ---- - -### 에이전트 설치 - -두 개의 소프트웨어 에이전트가 DZD에서 실행됩니다: - -```mermaid -flowchart TB - subgraph "귀하의 DZD" - CA[Config Agent] - TA[Telemetry Agent] - HW[스위치 하드웨어/소프트웨어] - end - - CA -->|구성 폴링| CTRL[컨트롤러 서비스] - CA -->|구성 적용| HW - - HW -->|메트릭| TA - TA -->|온체인 제출| BC[DoubleZero 레저] -``` - -| 에이전트 | 기능 | -|-------|--------------| -| **Config Agent** | 컨트롤러에서 구성을 가져와 스위치에 적용 | -| **Telemetry Agent** | 다른 장치에 대한 대기 시간/손실 측정, 온체인으로 메트릭 보고 | - -### 4.4단계: Config Agent 설치 - -#### 스위치에서 API 활성화 - -EOS 구성에 추가: - -``` -management api eos-sdk-rpc - transport grpc eapilocal - localhost loopback vrf default - service all - no disabled -``` - -!!! note "VRF 참고" - 관리 VRF 이름이 다른 경우(예: `management`) `default`를 해당 이름으로 교체하세요. - -#### 에이전트 다운로드 및 설치 - -```bash -# 스위치에서 bash 입력 -switch# bash -$ sudo bash -# cd /mnt/flash -# wget AGENT_DOWNLOAD_URL -# exit -$ exit - -# EOS 확장으로 설치 -switch# copy flash:AGENT_FILENAME extension: -switch# extension AGENT_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### 확장 확인 - -```bash -switch# show extensions -``` - -상태는 "A, I, B"여야 합니다: - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -AGENT_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### 에이전트 구성 및 시작 - -EOS 구성에 추가: - -``` -daemon doublezero-agent - exec /usr/local/bin/doublezero-agent -pubkey - no shut -``` - -!!! note "VRF 참고" - 관리 VRF가 `default`가 아닌 경우(즉, 네임스페이스가 `ns-default`가 아닌 경우) exec 명령 앞에 `exec /sbin/ip netns exec ns-`를 붙입니다. 예를 들어 VRF가 `management`인 경우: - ``` - daemon doublezero-agent - exec /sbin/ip netns exec ns-management /usr/local/bin/doublezero-agent -pubkey - no shut - ``` - -장치 공개 키를 `doublezero device list`의 `account` 열에서 가져옵니다. - -#### 실행 확인 - -```bash -switch# show agent doublezero-agent logs -``` - -"Starting doublezero-agent" 및 성공적인 컨트롤러 연결이 표시되어야 합니다. - -### 4.5단계: Telemetry Agent 설치 - -#### 메트릭 발행자 키를 장치에 복사 - -```bash -scp ~/.config/doublezero/metrics-publisher.json :/mnt/flash/metrics-publisher-keypair.json -``` - -#### 온체인에 메트릭 발행자 등록 - -```bash -doublezero device update \ - --pubkey \ - --metrics-publisher -``` - -metrics-publisher.json 파일에서 공개 키를 가져옵니다. - -#### 에이전트 다운로드 및 설치 - -```bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget TELEMETRY_DOWNLOAD_URL -# exit -$ exit - -# EOS 확장으로 설치 -switch# copy flash:TELEMETRY_FILENAME extension: -switch# extension TELEMETRY_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### 확장 확인 - -```bash -switch# show extensions -``` - -상태는 "A, I, B"여야 합니다: - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -TELEMETRY_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### 에이전트 구성 및 시작 - -EOS 구성에 추가: - -``` -daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut -``` - -!!! note "VRF 참고" - 관리 VRF가 `default`가 아닌 경우(즉, 네임스페이스가 `ns-default`가 아닌 경우) exec 명령에 `--management-namespace ns-`를 추가합니다. 예를 들어 VRF가 `management`인 경우: - ``` - daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --management-namespace ns-management --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut - ``` - -#### 실행 확인 - -```bash -switch# show agent doublezero-telemetry logs -``` - -"Starting telemetry collector" 및 "Starting submission loop"가 표시되어야 합니다. - ---- - -## 5단계: 링크 번인 - -!!! warning "모든 새 링크는 트래픽을 전달하기 전에 번인해야 합니다" - 새 링크는 프로덕션 트래픽을 활성화하기 전에 **최소 24시간 동안 드레인되어야 합니다**. 이 번인 요구사항은 링크가 서비스 준비가 되기 전에 약 20만 DZ 레저 슬롯(~20시간)의 클린 메트릭을 지정하는 [RFC12: 네트워크 프로비저닝](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md)에 정의되어 있습니다. - -에이전트가 설치 및 실행되면 최소 24시간 연속으로 [metrics.doublezero.xyz](https://metrics.doublezero.xyz)에서 링크를 모니터링합니다: - -- **"DoubleZero Device-Link Latencies"** 대시보드 — 시간에 따른 링크의 **제로 패킷 손실** 확인 -- **"DoubleZero Network Metrics"** 대시보드 — 링크의 **제로 오류** 확인 - -번인 기간이 제로 손실 및 제로 오류의 클린 링크를 보여준 후에만 링크의 드레인을 해제합니다. - ---- - -## 6단계: 검증 및 활성화 - -모든 것이 작동하는지 확인하기 위해 이 체크리스트를 실행합니다. - -!!! warning "장치는 잠금 상태로 시작됩니다 (`max_users = 0`)" - 장치가 생성되면 `max_users`가 기본적으로 **0**으로 설정됩니다. 즉, 아직 사용자가 연결할 수 없습니다. 이는 의도적인 것입니다 — 사용자 트래픽을 허용하기 전에 모든 것이 작동하는지 확인해야 합니다. - - **`max_users`를 0 이상으로 설정하기 전에 다음을 완료해야 합니다:** - - 1. 모든 링크가 [metrics.doublezero.xyz](https://metrics.doublezero.xyz)에서 제로 손실/오류로 **24시간 번인**을 완료했는지 확인 - 2. **DZ/Malbec Labs와 조율**하여 연결 테스트 실행: - - 테스트 사용자가 장치에 연결할 수 있는가? - - 사용자가 DZ 네트워크를 통해 경로를 수신하는가? - - 사용자가 DZ 네트워크를 통해 엔드-투-엔드로 트래픽을 라우팅할 수 있는가? - 3. DZ/ML이 테스트 통과를 확인한 후에만 max_users를 96으로 설정합니다: - - ```bash - doublezero device update --pubkey --max-users 96 - ``` - -### 장치 확인 - -```bash -# 장치가 "activated" 상태로 표시되어야 합니다 -doublezero device list | grep -``` - -**예상 출력:** - -``` - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -```bash -# 인터페이스가 나열되어야 합니다 -doublezero device interface list | grep -``` - -**예상 출력:** - -``` - nyc-dz001 | Loopback255 | loopback | vpnv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.91/32 | 56 | false | activated - nyc-dz001 | Loopback256 | loopback | ipv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.100/32 | 0 | false | activated - nyc-dz001 | Ethernet1/1 | physical | none | none | none | 0 | 0 | 1500 | static | 0 | | 0 | false | activated -``` - -### 링크 확인 - -```bash -# 링크가 "activated" 상태를 표시해야 합니다 -doublezero link list | grep -``` - -**예상 출력:** - -``` - 8vkYpXaBW8RuknJq... | nyc-lax-wan01 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -### 에이전트 확인 - -스위치에서: - -```bash -# Config Agent가 성공적인 구성 가져오기를 표시해야 합니다 -switch# show agent doublezero-agent logs | tail -20 - -# Telemetry Agent가 성공적인 제출을 표시해야 합니다 -switch# show agent doublezero-telemetry logs | tail -20 -``` - -### 최종 검증 다이어그램 - -```mermaid -flowchart TB - subgraph "검증 체크리스트" - D[장치 상태: activated?] - I[인터페이스: 등록됨?] - L[링크: activated?] - CA[Config Agent: 구성 가져오는 중?] - TA[Telemetry Agent: 메트릭 제출 중?] - end - - D --> PASS - I --> PASS - L --> PASS - CA --> PASS - TA --> PASS - - PASS[모든 확인 통과] --> NOTIFY[DZF/Malbec Labs에 통지
기술적으로 준비됨!] +Signature: 7pQw2R...truncated...4xKm9 ``` ---- - -## 문제 해결 - -### 장치 생성 실패 - -- 서비스 키가 승인되었는지 확인합니다 (`doublezero contributor list`) -- 위치 및 exchange 코드가 유효한지 확인합니다 -- DZ 프리픽스가 유효한 공개 IP 범위인지 확인합니다 - -### "requested" 상태에서 멈춘 링크 - -- DZX 링크는 다른 기여자의 수락이 필요합니다 -- 상대방에게 `doublezero link accept` 실행 요청 - -### Config Agent가 연결되지 않음 - -- 관리 네트워크에 인터넷 액세스가 있는지 확인합니다 -- VRF 구성이 설정과 일치하는지 확인합니다 -- 장치 공개 키가 올바른지 확인합니다 - -### Telemetry Agent가 제출하지 않음 - -- 메트릭 발행자 키가 온체인에 등록되었는지 확인합니다 -- 스위치에 키쌍 파일이 존재하는지 확인합니다 -- 장치 계정 공개 키가 올바른지 확인합니다 - ---- +WAN 또는 DZX 링크 엔드포인트로 사용될 각 인터페이스에 대해 이 작업을 반복합니다. CYOA 및 DIA 인터페이스는 다음 단계에서 별도로 등록됩니다. -## 다음 단계 +### Step 3.5: CYOA 인터페이스 생성 (Edge/Hybrid 디바이스용) -- 에이전트 업그레이드 및 링크 관리에 대한 [운영 가이드](contribute-operations.md) 검토 -- 용어 정의는 [용어집](glossary.md) 확인 -- 문제가 발생하면 DZF/Malbec Labs에 문의 +Hybrid 및 Edge DZD에는 사용자가 GRE 터널을 종단하는 **두 개의 공용 IP 주소**가 필요합니다. 사용자는 유니캐스트, 멀티캐스트, 또는 둘 다를 \ No newline at end of file diff --git a/docs/contribute-provisioning.pt.md b/docs/contribute-provisioning.pt.md index 72081d9..e5a79a6 100644 --- a/docs/contribute-provisioning.pt.md +++ b/docs/contribute-provisioning.pt.md @@ -1,62 +1,102 @@ -# Guia de Provisionamento de Dispositivos -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Guia passo a passo para provisionar um Dispositivo DoubleZero (DZD) e registrar suas interfaces e funções on-chain. +--- +# Guia de Provisionamento de Dispositivos -Este guia orienta você no provisionamento de um Dispositivo DoubleZero (DZD) do início ao fim. Cada fase corresponde à [Lista de Verificação de Integração](contribute-overview.md#onboarding-checklist). +Este guia orienta você no provisionamento de um Dispositivo DoubleZero (DZD) do início ao fim. Cada fase corresponde ao [Checklist de Integração](contribute-overview.md#onboarding-checklist). --- ## Como Tudo Se Encaixa -Antes de mergulhar nas etapas, aqui está a visão geral do que você está construindo: +Este guia orienta você no registro da sua infraestrutura on-chain para que a rede DoubleZero possa rotear tráfego através dela. Quanto mais completamente seu dispositivo estiver registrado, mais útil ele será para a rede. Uma representação on-chain completa do seu dispositivo permite melhor resolução de problemas, planejamento de capacidade e permite que o controlador tome decisões informadas. Com o tempo, o objetivo é que o controlador assuma mais responsabilidade de configuração. + +### Conceitos-chave + +**Interfaces** + +As interfaces em um DZD vêm em diferentes formas: portas Ethernet, port channels (LAGs compostos por múltiplas portas Ethernet) e loopbacks. Cada interface que desempenha um papel na rede precisa ser registrada on-chain com as flags apropriadas para que o protocolo saiba o que ela faz. + +Portas Ethernet e port channels podem desempenhar as seguintes funções: + +| Flag | O que significa | +|------|-----------------| +| `--interface-dia dia` | Marca a interface como uplink de acesso direto à internet | +| `--interface-cyoa ` | Declara como os usuários estabelecem túneis GRE através desta interface (ex: pela internet pública, via link de peering privado) | +| `--user-tunnel-endpoint true` | Esta interface possui um IP público no qual os usuários terminam túneis GRE | + +Interfaces usadas para links WAN ou DZX não possuem uma flag específica — elas são registradas com sua largura de banda e então referenciadas quando o link é criado. + +Interfaces loopback servem a diversos propósitos: + +| Loopback | O que significa | +|----------|-----------------| +| **Loopback100 / 101** | Possuem IPs públicos nos quais os usuários terminam túneis GRE. Registrados com `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Registrado para que o controlador possa atribuir um IP usado para router ID BGP, peering VPN-IPv4 (unicast), identidade IS-IS e segment routing | +| **Loopback256** (`ipv4`) | Registrado para que o controlador possa atribuir um IP usado para peering BGP IPv4 (multicast) e sessões MSDP | + +**Links** + +Links são registrados separadamente das interfaces, e as interfaces devem existir on-chain antes que um link possa referenciá-las. Quando você cria um link WAN ou DZX, você especifica uma interface já registrada como o endpoint físico do link. Nem todas as interfaces estão vinculadas a um link: interfaces DIA, CYOA e loopback não são conectadas a um link. + +| Termo | O que significa | +|-------|-----------------| +| **Link WAN** | Um link entre dois dos seus próprios DZDs | +| **Link DZX** | Um link entre seu DZD e o DZD de outro contribuidor | + +### Visão geral da arquitetura ```mermaid flowchart TB subgraph Onchain - SC[Ledger DoubleZero] + SC[DoubleZero Ledger] end - subgraph Sua Infraestrutura - MGMT[Servidor de Gerenciamento
CLI DoubleZero] - DZD[Seu DZD
Switch Arista] - DZD ---|Link WAN| DZD2[Seu outro DZD] + subgraph Your Infrastructure + MGMT[Servidor de Gerenciamento
DoubleZero CLI] + subgraph DZD[Seu DZD] + CYOA["Interface DIA · CYOA
(uplink voltado ao usuário)"] + WAN_INTF["Interface de link WAN"] + DZX_INTF["Interface de link DZX"] + LO100["Loopback100/101
(endpoint de túnel do usuário)"] + end + DZD2[Seu outro DZD] end - subgraph Outro Contribuidor + subgraph Other Contributor OtherDZD[DZD deles] end - subgraph Usuários - VAL[Validadores] - RPC[Nós RPC] - end + USERS["Usuários"] MGMT -.->|Registra dispositivos,
links, interfaces| SC - DZD ---|Link DZX| OtherDZD - VAL ---|Conecta via Internet| DZD - RPC ---|Conecta via Internet| DZD + WAN_INTF ---|Link WAN| DZD2 + DZX_INTF ---|Link DZX| OtherDZD + USERS -.|Túnel GRE|.-> CYOA + CYOA ---|roteia para| LO100 ``` --- ## Fase 1: Pré-requisitos -Antes de poder provisionar um dispositivo, você precisa do hardware físico configurado e alguns endereços IP alocados. +Antes de provisionar um dispositivo, você precisa ter o hardware físico configurado e alguns endereços IP alocados. ### O Que Você Precisa | Requisito | Por Que É Necessário | -|-------------|-----------------| -| **Hardware DZD** | Switch Arista 7280CR3A (consulte [especificações de hardware](contribute.md#hardware-requirements)) | -| **Espaço em Rack** | 4U com fluxo de ar adequado | -| **Energia** | Alimentações redundantes, ~4KW recomendado | +|-----------|----------------------| +| **Hardware DZD** | Switch Arista 7280CR3A (veja [especificações de hardware](contribute.md#hardware-requirements)) | +| **Espaço em Rack** | 1U por DZD, com fluxo de ar adequado. Veja [Rack e Energia](contribute.md#rack-power-requirements) | +| **Energia** | Duas alimentações independentes, cada uma capaz de suportar toda a carga sozinha. Veja [Rack e Energia](contribute.md#rack-power-requirements) | | **Acesso de Gerenciamento** | Acesso SSH/console para configurar o switch | -| **Conectividade à Internet** | Para publicação de métricas e busca de configuração do controlador | +| **Conectividade com a Internet** | Para publicação de métricas e para buscar configuração do controlador | | **Bloco IPv4 Público** | Mínimo /29 para o pool de prefixos DZ (veja abaixo) | -### Instalar o CLI do DoubleZero +### Instalar o CLI DoubleZero -O CLI do DoubleZero (`doublezero`) é usado ao longo do provisionamento para registrar dispositivos, criar links e gerenciar sua contribuição. Deve ser instalado em um **servidor ou VM de gerenciamento** — não no próprio switch DZD. O switch executa apenas o Config Agent e o Telemetry Agent (instalados na [Fase 4](#fase-4-estabelecimento-de-link-instalação-de-agentes)). +O CLI DoubleZero (`doublezero`) é usado durante todo o provisionamento para registrar dispositivos, criar links e gerenciar sua contribuição. Ele deve ser instalado em um **servidor de gerenciamento ou VM** — não no switch DZD em si. O switch executa apenas o Config Agent e o Telemetry Agent (instalados na [Fase 4](#fase-4-estabelecimento-de-links-instalação-de-agentes)). **Ubuntu / Debian:** ```bash @@ -70,14 +110,14 @@ curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.rpm.sh | sudo yum install doublezero ``` -Verificar se o daemon está em execução: +Verifique se o daemon está em execução: ```bash sudo systemctl status doublezerod ``` -### Entendendo seu Prefixo DZ +### Entendendo Seu Prefixo DZ -Seu prefixo DZ é um bloco de endereços IP públicos que o protocolo DoubleZero gerencia para alocação de IP. +Seu prefixo DZ é um bloco de endereços IP públicos que o protocolo DoubleZero gerencia para alocação de IPs. ```mermaid flowchart LR @@ -97,16 +137,15 @@ flowchart LR **Como os prefixos DZ são usados:** - **Primeiro IP**: Reservado para seu dispositivo (atribuído à interface Loopback100) -- **IPs restantes**: Alocados para tipos específicos de usuários que se conectam ao seu DZD: +- **IPs restantes**: Alocados para tipos específicos de usuários conectando ao seu DZD: - Usuários `IBRLWithAllocatedIP` - - Usuários `EdgeFiltering` - - Publicadores multicast -- **Usuários IBRL**: NÃO consomem deste pool (usam seu próprio IP público) + - Usuários `EdgeFiltering` (caso de uso futuro) +- **Usuários IBRL**: NÃO consomem deste pool (eles usam seu próprio IP público) -!!! warning "Regras de Prefixo DZ" - **Você NÃO PODE usar esses endereços para:** +!!! warning "Regras do Prefixo DZ" + **Você NÃO PODE usar estes endereços para:** - - Seu próprio equipamento de rede + - Seus próprios equipamentos de rede - Links ponto a ponto em interfaces DIA - Interfaces de gerenciamento - Qualquer infraestrutura fora do protocolo DZ @@ -114,28 +153,30 @@ flowchart LR **Requisitos:** - Devem ser endereços IPv4 **globalmente roteáveis (públicos)** - - Intervalos de IP privados (10.x, 172.16-31.x, 192.168.x) são rejeitados pelo contrato inteligente - - **Tamanho mínimo: /29** (8 endereços), prefixos maiores são preferidos (por exemplo, /28, /27) - - Todo o bloco deve estar disponível — não pré-aloque nenhum endereço + - Faixas de IP privado (10.x, 172.16-31.x, 192.168.x) são rejeitadas pelo smart contract + - **Tamanho mínimo: /29** (8 endereços), prefixos maiores são preferíveis (ex: /28, /27) + - O bloco inteiro deve estar disponível — não pré-aloque nenhum endereço - Se você precisar de endereços para seu próprio equipamento (IPs de interface DIA, gerenciamento, etc.), use um **pool de endereços separado**. + Se você precisar de endereços para seus próprios equipamentos (IPs de interface DIA, gerenciamento, etc.), use um **pool de endereços separado**. --- -## Fase 2: Configuração de Conta +## Fase 2: Configuração da Conta -Nesta fase, você cria as chaves criptográficas que identificam você e seus dispositivos na rede. +Nesta fase, você cria as chaves criptográficas que identificam você e seus dispositivos na rede, e define onde suas recompensas devem ser pagas. + +Três chaves resultam desta fase: uma chave de serviço, uma chave de publicador de métricas e uma chave de gerenciador de recompensas. Envie as chaves públicas de todas as três para a DZF juntas no [Passo 2.4](#passo-24-enviar-chaves-para-a-dzf). [Gerenciamento de Recompensas](contribute-rewards.md) cobre o lado das recompensas em detalhes. ### Onde Executar o CLI !!! warning "NÃO instale o CLI no seu switch" - O CLI do DoubleZero (`doublezero`) deve ser instalado em um **servidor ou VM de gerenciamento**, não no seu switch Arista. + O CLI DoubleZero (`doublezero`) deve ser instalado em um **servidor de gerenciamento ou VM**, não no seu switch Arista. ```mermaid flowchart LR - subgraph "Servidor/VM de Gerenciamento" - CLI[CLI DoubleZero] - KEYS[Seus Keypairs] + subgraph "Servidor de Gerenciamento/VM" + CLI[DoubleZero CLI] + KEYS[Seus Pares de Chaves] end subgraph "Seu Switch DZD" @@ -144,36 +185,42 @@ Nesta fase, você cria as chaves criptográficas que identificam você e seus di end CLI -->|Cria dispositivos, links| BC[Blockchain] - CA -->|Busca config| CTRL[Controlador] + CA -->|Busca configuração| CTRL[Controlador] TA -->|Envia métricas| BC ``` | Instalar no Servidor de Gerenciamento | Instalar no Switch | - |-----------------------------|-------------------| + |---------------------------------------|---------------------| | CLI `doublezero` | Config Agent | - | Seu keypair de serviço | Telemetry Agent | - | Seu keypair do editor de métricas | Keypair do editor de métricas (cópia) | + | Seu par de chaves de serviço | Telemetry Agent | + | Seu par de chaves de publicador de métricas | Par de chaves de publicador de métricas (cópia) | ### O Que São Chaves? -Pense nas chaves como credenciais de login seguras: +Pense nas chaves como credenciais seguras de login: -- **Chave de Serviço**: Sua identidade de contribuidor — usada para executar comandos CLI -- **Chave do Editor de Métricas**: A identidade do seu dispositivo para enviar dados de telemetria +- **Chave de Serviço**: Sua identidade de contribuidor - usada para executar comandos do CLI +- **Chave de Publicador de Métricas**: A identidade do seu dispositivo para enviar dados de telemetria +- **Chave de Gerenciador de Recompensas**: Controla quais carteiras recebem suas recompensas - veja [Gerenciamento de Recompensas](contribute-rewards.md) -Ambas são keypairs criptográficos (uma chave pública que você compartilha, uma chave privada que você mantém em segredo). +Todas as três são pares de chaves criptográficas (uma chave pública que você compartilha, uma chave privada que você mantém em segredo). ```mermaid flowchart LR subgraph "Suas Chaves" SK[Chave de Serviço
~/.config/solana/id.json] - MK[Chave do Editor de Métricas
~/.config/doublezero/metrics-publisher.json] + MK[Chave de Publicador de Métricas
~/.config/doublezero/metrics-publisher.json] + RK[Chave de Gerenciador de Recompensas
manter offline] end SK -->|Usada para| CLI[Comandos CLI
doublezero device create
doublezero link create] MK -->|Usada para| TEL[Telemetry Agent
Envia métricas onchain] + RK -->|Usada para| REW[Portal de Recompensas
Define carteiras destinatárias] ``` +!!! note "Mantenha a chave de gerenciador de recompensas separada" + A chave de serviço e a chave de publicador de métricas ficam no seu servidor de gerenciamento e no switch. A chave de gerenciador de recompensas controla para onde seu dinheiro vai, então mantenha-a fora dessas máquinas. Ela só é necessária quando você altera suas carteiras destinatárias. + ### Passo 2.1: Gerar Sua Chave de Serviço Esta é sua identidade principal para interagir com o DoubleZero. @@ -182,9 +229,9 @@ Esta é sua identidade principal para interagir com o DoubleZero. doublezero keygen ``` -Isso cria um keypair no local padrão. A saída mostra sua **chave pública** — isso é o que você compartilhará com a DZF. +Isso cria um par de chaves no local padrão. A saída mostra sua **chave pública** - é isso que você compartilhará com a DZF. -### Passo 2.2: Gerar Sua Chave do Editor de Métricas +### Passo 2.2: Gerar Sua Chave de Publicador de Métricas Esta chave é usada pelo Telemetry Agent para assinar envios de métricas. @@ -192,19 +239,34 @@ Esta chave é usada pelo Telemetry Agent para assinar envios de métricas. doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Passo 2.3: Enviar Chaves para a DZF +### Passo 2.3: Criar Sua Carteira de Gerenciador de Recompensas + +Esta é a terceira chave. Ela controla quais carteiras recebem suas recompensas, e nunca as retém. + +Crie uma carteira Solana que você controle e possa assinar, depois financie-a com cerca de 0,01 SOL para cobrir taxas de transação. Uma carteira de hardware é uma boa escolha. Não reutilize sua chave de serviço. + +Você só precisa da carteira neste momento. Você definirá as carteiras que realmente recebem suas recompensas no [Passo 2.7](#passo-27-definir-seus-destinatários-de-recompensa), depois que a DZF tiver registrado esta chave. + +### Passo 2.4: Enviar Chaves para a DZF Entre em contato com a DoubleZero Foundation ou Malbec Labs e forneça: 1. Sua **chave pública de serviço** -2. Seu **nome de usuário GitHub** (para acesso ao repositório) +2. Sua **chave pública de gerenciador de recompensas** (do Passo 2.3) +3. Seu **nome de usuário do GitHub** (para acesso ao repositório) + +Envie as três juntas. A DZF registra a chave de serviço e a chave de gerenciador de recompensas em transações onchain separadas, então enviá-las ao mesmo tempo economiza uma ida e volta. + +!!! danger "Apenas chaves públicas" + Nunca envie uma chave privada ou um arquivo de par de chaves para ninguém, incluindo a DZF. A DZF só precisa das suas chaves públicas. Eles irão: - Criar sua **conta de contribuidor** onchain -- Conceder acesso ao **repositório de contribuidores** privado +- Registrar sua **chave de gerenciador de recompensas** associada à sua chave de serviço +- Conceder acesso ao **repositório privado de contribuidores** -### Passo 2.4: Verificar Sua Conta +### Passo 2.5: Verificar Sua Conta Uma vez confirmado, verifique se sua conta de contribuidor existe: @@ -214,58 +276,98 @@ doublezero contributor list Você deve ver seu código de contribuidor na lista. -### Passo 2.5: Acessar o Repositório de Contribuidores +Verifique se sua chave de gerenciador de recompensas também foi registrada: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` + +A coluna `manager` deve mostrar sua chave pública de gerenciador de recompensas. Se estiver vazia, peça à DZF para completar essa etapa. + +### Passo 2.6: Acessar o Repositório de Contribuidores O repositório [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contém: -- Configurações base do dispositivo +- Configurações base de dispositivos - Perfis TCAM -- Configurações ACL -- Instruções de configuração adicionais +- Configurações de ACL +- Instruções adicionais de configuração Siga as instruções lá para configuração específica do dispositivo. +### Passo 2.7: Definir Seus Destinatários de Recompensa + +Agora defina quais carteiras recebem suas recompensas, e em quais proporções. Faça isso antes que seu dispositivo comece a transportar tráfego. As recompensas se acumulam a partir do momento em que seus links estão ativos, mas o protocolo não pode pagá-las até que você tenha indicado carteiras destinatárias. + +Acesse [doublezero.xyz/rewards](https://doublezero.xyz/rewards) com sua carteira de gerenciador de recompensas, selecione sua chave de serviço e insira cada carteira destinatária e sua porcentagem. As porcentagens devem somar 100. + +!!! warning "Cada destinatário precisa de uma conta de token 2Z" + O protocolo envia 2Z com uma transferência de token simples e não cria a conta de token para você. Uma carteira destinatária sem conta de token 2Z faz com que o pagamento daquela época falhe. + +Veja [Gerenciamento de Recompensas](contribute-rewards.md) para o passo a passo completo, incluindo a alternativa via CLI, como verificar a conta de token e como verificar o resultado. + --- -## Fase 3: Provisionamento de Dispositivos +## Fase 3: Provisionamento do Dispositivo + +Agora você registrará seu dispositivo físico na blockchain e configurará suas interfaces. -Agora você registrará seu dispositivo físico no blockchain e configurará suas interfaces. +### Entendendo os Tipos de Dispositivo -### Entendendo os Tipos de Dispositivos +**Edge** — aceita apenas conexões de usuários ```mermaid -flowchart TB - subgraph "Dispositivo Edge" - E[DZD Edge] - EU[Usuários se conectam aqui] - EU --> E - E <-->|Link DZX| ED[Outro DZD] +flowchart LR + subgraph EDZD[DZD Edge] + E_CYOA["Interface DIA · CYOA"] + E_TUN["Loopback100/101 + (endpoint de túnel do usuário)"] + E_DZX["Interface de link DZX"] + E_CYOA --- E_TUN end + EU["Usuários"] -.|Túnel GRE|.-> E_CYOA + E_DZX <-->|Link DZX| ED["DZD (contribuidor diferente)"] +``` + +**Transit** — move tráfego entre dispositivos, sem conexões de usuários - subgraph "Dispositivo Transit" - T[DZD Transit] - T <-->|Link WAN| T2[Outro DZD] - T <-->|Link DZX| TD[Outro DZD] +```mermaid +flowchart LR + subgraph TDZD[DZD Transit] + T_WAN["Interface de link WAN"] + T_DZX["Interface de link DZX"] end + T_WAN <-->|Link WAN| T2["DZD (mesmo contribuidor)"] + T_DZX <-->|Link DZX| TD["DZD (contribuidor diferente)"] +``` - subgraph "Dispositivo Hybrid" - H[DZD Hybrid] - HU[Usuários se conectam aqui] - HU --> H - H <-->|Link WAN| H2[Outro DZD] - H <-->|Link DZX| HD[Outro DZD] +**Hybrid** — conexões de usuários e backbone, mais comum + +```mermaid +flowchart LR + subgraph HDZD[DZD Hybrid] + H_CYOA["Interface DIA · CYOA"] + H_TUN["Loopback100/101 + (endpoint de túnel do usuário)"] + H_WAN["Interface de link WAN"] + H_DZX["Interface de link DZX"] + H_CYOA --- H_TUN end + HU["Usuários"] -.|Túnel GRE|.-> H_CYOA + H_WAN <-->|Link WAN| H2["DZD (mesmo contribuidor)"] + H_DZX <-->|Link DZX| HD["DZD (contribuidor diferente)"] ``` | Tipo | O Que Faz | Quando Usar | -|------|--------------|-------------| -| **Edge** | Aceita conexões de usuários apenas | Localização única, voltado apenas para usuários | +|------|-----------|-------------| +| **Edge** | Aceita apenas conexões de usuários | Localização única, apenas voltado ao usuário | | **Transit** | Move tráfego entre dispositivos | Conectividade de backbone, sem usuários | -| **Hybrid** | Conexões de usuários E backbone | Mais comum — faz tudo | +| **Hybrid** | Conexões de usuários E backbone | Mais comum - faz tudo | ### Passo 3.1: Encontrar Sua Localização e Exchange -Antes de criar seu dispositivo, consulte os códigos para sua localização de data center e exchange mais próxima: +Antes de criar seu dispositivo, consulte os códigos da localização do seu data center e do exchange mais próximo: ```bash # Listar localizações disponíveis (data centers) @@ -277,15 +379,15 @@ doublezero exchange list ### Passo 3.2: Criar Seu Dispositivo Onchain -Registrar seu dispositivo no blockchain: +Registre seu dispositivo na blockchain: ```bash doublezero device create \ --code \ --contributor \ --device-type hybrid \ - --location \ - --exchange \ + --location \ + --exchange \ --public-ip \ --dz-prefixes ``` @@ -309,25 +411,25 @@ doublezero device create \ Signature: 4vKz8H...truncated...7xPq2 ``` -Verificar se seu dispositivo foi criado: +Verifique se seu dispositivo foi criado: ```bash doublezero device list | grep nyc-dz001 ``` -**Parâmetros explicados:** +**Explicação dos parâmetros:** | Parâmetro | O Que Significa | -|-----------|---------------| -| `--code` | Um nome único para seu dispositivo (por exemplo, `nyc-dz001`) | +|-----------|-----------------| +| `--code` | Um nome único para seu dispositivo (ex: `nyc-dz001`) | | `--contributor` | Seu código de contribuidor (fornecido pela DZF) | | `--device-type` | `hybrid`, `transit` ou `edge` | -| `--location` | Código do data center em `location list` | -| `--exchange` | Código da exchange mais próxima em `exchange list` | -| `--public-ip` | O IP público onde os usuários se conectam ao seu dispositivo via internet | -| `--dz-prefixes` | Seu bloco de IP alocado para usuários | +| `--location` | Código do data center obtido de `location list` | +| `--exchange` | Código do exchange mais próximo obtido de `exchange list` | +| `--public-ip` | O IP público onde os usuários se conectam ao seu dispositivo pela internet | +| `--dz-prefixes` | Seu bloco de IPs alocado para usuários | -### Passo 3.3: Criar Interfaces Loopback Necessárias +### Passo 3.3: Criar Interfaces Loopback Obrigatórias Todo dispositivo precisa de duas interfaces loopback para roteamento interno: @@ -347,11 +449,18 @@ Signature: 3mNx9K...truncated...8wRt5 ### Passo 3.4: Criar Interfaces Físicas -Registrar as portas físicas que você usará: +Registre as interfaces físicas que serão usadas para links WAN ou DZX. Estas interfaces devem existir on-chain antes que você possa criar um link que as referencie. Neste passo você apenas registra a interface e sua largura de banda — o link é criado em um passo posterior. ```bash -# Interface básica -doublezero device interface create Ethernet1/1 +doublezero device interface create \ + --bandwidth +``` + +**Exemplo:** + +```bash +doublezero device interface create nyc-dz001 Ethernet1/1 \ + --bandwidth 10Gbps ``` **Saída esperada:** @@ -360,34 +469,36 @@ doublezero device interface create Ethernet1/1 Signature: 7pQw2R...truncated...4xKm9 ``` +Repita isso para cada interface que será usada como endpoint de link WAN ou DZX. Interfaces CYOA e DIA são registradas separadamente no próximo passo. + ### Passo 3.5: Criar Interface CYOA (para dispositivos Edge/Hybrid) -DZDs híbridos e edge precisam de **dois endereços IP públicos** nos quais os usuários terminam seus túneis GRE. Os usuários podem se conectar via unicast, multicast, ou ambos, e qual IP serve qual propósito é rotacionado por usuário. +DZDs hybrid e edge precisam de **dois endereços IP públicos** nos quais os usuários terminam seus túneis GRE. Os usuários podem se conectar via unicast, multicast ou ambos, e qual IP serve a qual propósito rotaciona por usuário. -Ambos os IPs devem ser registrados com `--user-tunnel-endpoint true`, em uma interface física ou em um loopback. Isso inclui o IP fornecido no momento da criação do dispositivo; esse IP ainda precisa ser registrado explicitamente aqui. +Ambos os IPs devem ser registrados com `--user-tunnel-endpoint true`, em uma interface física ou em um loopback. Isso inclui o IP que você forneceu no momento da criação do dispositivo — esse IP ainda precisa ser explicitamente registrado aqui. -Se você estiver com restrição de IP, pode usar o primeiro `/32` do seu prefixo DZ como um dos dois IPs. +Se você tem restrição de IPs, pode usar o primeiro `/32` do seu prefixo DZ como um dos dois IPs. #### CYOA e DIA | Tipo | Flag | Propósito | |------|------|-----------| | DIA | `--interface-dia dia` | Marca a porta como acesso direto à internet | -| CYOA | `--interface-cyoa ` | Declara como os usuários conectam túneis GRE ao seu dispositivo | +| CYOA | `--interface-cyoa ` | Declara como os usuários conectam túneis GRE ao seu dispositivo | -O flag CYOA é sempre definido em uma **interface física** (porta Ethernet ou port channel). Nunca em um loopback. +A flag CYOA é sempre definida em uma **interface física** (porta Ethernet ou port channel). Nunca em um loopback. | Subtipo CYOA | Quando usar | -|-------------|------------| -| `gre-over-dia` | Usuários se conectam pela internet pública. O mais comum. | +|--------------|-------------| +| `gre-over-dia` | Usuários se conectam pela internet pública. Mais comum. | | `gre-over-private-peering` | Usuários se conectam via cross-connect direto ou circuito privado | | `gre-over-public-peering` | Usuários fazem peering com você em um Internet Exchange (IX) | -| `gre-over-fabric` | Usuários são co-localizados e se conectam por um fabric local | -| `gre-over-cable` | Conexão de cabo direto a um único usuário dedicado | +| `gre-over-fabric` | Usuários estão co-localizados e se conectam via fabric local | +| `gre-over-cable` | Conexão por cabo direto a um único usuário dedicado | #### Cenário A: Interface física única -Um uplink físico para o ISP. Ethernet1/1 é a interface CYOA e DIA e carrega um dos dois IPs públicos. Loopback100 carrega o segundo IP público. +Um único uplink físico para o ISP. Ethernet1/1 é a interface CYOA e DIA e possui um dos dois IPs públicos. Loopback100 possui o segundo IP público. ```mermaid flowchart LR @@ -396,9 +507,9 @@ flowchart LR subgraph DZD["DZD"] E1["Eth1/1 203.0.113.1/30 - CYOA · DIA · user tunnel endpoint"] + CYOA · DIA · endpoint de túnel do usuário"] LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n endpoint de túnel do usuário"] E1 --- LO end @@ -412,10 +523,10 @@ flowchart LR | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuída pelo contribuidor | velocidade da porta | taxa comprometida | `bgp` ou `static` | `true` | +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade da porta | taxa garantida | `bgp` ou `static` | `true` | | Loopback100 | — | — | seu /32 público | `0bps` | — | — | `true` | -Exemplo de comandos para o Cenário A: +Exemplo de comandos a executar baseados no Cenário A: ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -434,24 +545,24 @@ doublezero device interface create mydzd-nyc01 Loopback100 \ #### Cenário B: Port channel (LAG) -O DZD se conecta ao dispositivo upstream via port channel com um IP. O port channel carrega um IP público e é o endpoint CYOA. Loopback100 carrega o segundo IP público. +O DZD se conecta ao dispositivo upstream via um port channel com um IP. O port channel possui um IP público e é o endpoint CYOA. Loopback100 possui o segundo IP público. ```mermaid flowchart LR USERS(["Usuários Finais"]) - subgraph SW["Roteador/Switch Upstream"] + subgraph SW["Roteador / Switch Upstream"] SWPC(["bond0 203.0.113.2/30"]) end subgraph DZD["DZD"] - subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · user tunnel endpoint"] + subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · endpoint de túnel do usuário"] E1["Eth1/1"] E2["Eth2/1"] end LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n endpoint de túnel do usuário"] PC --- LO end @@ -462,10 +573,10 @@ flowchart LR | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | IP/sub-rede atribuída pelo contribuidor | velocidade LAG combinada | taxa comprometida | `bgp` ou `static` | `true` | +| Port-Channel1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade combinada do LAG | taxa garantida | `bgp` ou `static` | `true` | | Loopback100 | — | — | seu /32 público | `0bps` | — | — | `true` | -Exemplo de comandos para o Cenário B: +Exemplo de comandos a executar baseados no Cenário B: ```bash doublezero device interface create mydzd-fra01 Port-Channel1 \ --interface-cyoa gre-over-dia \ @@ -482,531 +593,14 @@ doublezero device interface create mydzd-fra01 Loopback100 \ --user-tunnel-endpoint true ``` -#### Cenário C: Duplos uplinks físicos para roteadores separados -Cada interface física se conecta a um roteador upstream diferente. Os dois IPs públicos ficam em Loopback100 e Loopback101, ambos registrados como endpoints de túnel de usuário. +#### Cenário C: Uplinks físicos duplos para roteadores separados + +Cada interface física se conecta a um roteador upstream diferente. Os dois IPs públicos ficam em Loopback100 e Loopback101, ambos registrados como endpoints de túnel do usuário. ```mermaid flowchart LR USERS(["Usuários Finais"]) RA["Roteador A - 203.0.113.2/30"] - RB["Roteador B - 203.0.113.6/30"] - - subgraph DZD["DZD"] - E1["Eth1/1 - 203.0.113.1/30 - CYOA · DIA"] - E2["Eth2/1 - 203.0.113.5/30 - CYOA · DIA"] - LO0["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - LO1["Loopback101 - 198.51.100.2/32\n user tunnel endpoint"] - E1 --> LO0 - E2 --> LO1 - end - - RA -- "10GbE" --- E1 - RB -- "10GbE" --- E2 - USERS -. "Túneis GRE" .-> LO0 - USERS -. "Túneis GRE" .-> LO1 -``` - -| Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuída pelo contribuidor | velocidade da porta | taxa comprometida | `bgp` ou `static` | — | -| Ethernet2/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuída pelo contribuidor | velocidade da porta | taxa comprometida | `bgp` ou `static` | — | -| Loopback100 | — | — | seu /32 público | `0bps` | — | — | `true` | -| Loopback101 | — | — | seu /32 público | `0bps` | — | — | `true` | - -Exemplo de comandos para o Cenário C: -```bash -doublezero device interface create mydzd-ams01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Ethernet2/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.5/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-ams01 Loopback101 \ - --ip-net 198.51.100.2/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -### Passo 3.6: Verificar Seu Dispositivo - -```bash -doublezero device list -``` - -**Exemplo de saída:** - -``` - account | code | contributor | location | exchange | device_type | public_ip | dz_prefixes | users | max_users | status | health | mgmt_vrf | owner - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -Seu dispositivo deve aparecer com status `activated`. - ---- - -## Fase 4: Estabelecimento de Link & Instalação de Agentes - -Os links conectam seu dispositivo ao restante da rede DoubleZero. - -### Entendendo os Links - -```mermaid -flowchart LR - subgraph "Sua Rede" - D1[Seu DZD 1
NYC] - D2[Seu DZD 2
LAX] - end - - subgraph "Outro Contribuidor" - O1[DZD deles
NYC] - end - - D1 ---|Link WAN
Mesmo contribuidor| D2 - D1 ---|Link DZX
Contribuidores diferentes| O1 -``` - -| Tipo de Link | Conecta | Aceitação | -|-----------|----------|------------| -| **Link WAN** | Dois dos SEUS dispositivos | Automática (você é dono de ambos) | -| **Link DZX** | Seu dispositivo com OUTRO contribuidor | Requer aceitação deles | - -### Passo 4.1: Criar Links WAN (se você tiver múltiplos dispositivos) - -Links WAN conectam seus próprios dispositivos: - -```bash -doublezero link create wan \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --side-z-interface \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 20 \ - --jitter-ms 1 -``` - -**Exemplo:** - -```bash -doublezero link create wan \ - --code nyc-lax-wan01 \ - --contributor acme \ - --side-a nyc-dz001 \ - --side-a-interface Ethernet3/1 \ - --side-z lax-dz001 \ - --side-z-interface Ethernet3/1 \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 65 \ - --jitter-ms 1 -``` - -**Saída esperada:** - -``` -Signature: 5tNm7K...truncated...9pRw2 -``` - -### Passo 4.2: Criar Links DZX - -Os links DZX conectam seu dispositivo diretamente ao DZD de outro contribuidor: - -```bash -doublezero link create dzx \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --bandwidth \ - --mtu \ - --delay-ms \ - --jitter-ms -``` - -**Saída esperada:** - -``` -Signature: 8mKp3W...truncated...2nRx7 -``` - -Após criar um link DZX, o outro contribuidor deve aceitá-lo: - -```bash -# O OUTRO contribuidor executa isso -doublezero link accept \ - --code \ - --side-z-interface -``` - -**Saída esperada (para o contribuidor que aceita):** - -``` -Signature: 6vQt9L...truncated...3wPm4 -``` - -### Passo 4.3: Verificar Links - -```bash -doublezero link list -``` - -**Exemplo de saída:** - -``` - account | code | contributor | side_a_name | side_a_iface_name | side_z_name | side_z_iface_name | link_type | bandwidth | mtu | delay_ms | jitter_ms | delay_override_ms | tunnel_id | tunnel_net | status | health | owner - 8vkYpXaBW8RuknJq... | nyc-dz001:lax-dz001 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -Os links devem mostrar status `activated` uma vez que ambos os lados estejam configurados. - ---- - -### Instalação de Agentes - -Dois agentes de software são executados no seu DZD: - -```mermaid -flowchart TB - subgraph "Seu DZD" - CA[Config Agent] - TA[Telemetry Agent] - HW[Hardware/Software do Switch] - end - - CA -->|Busca config| CTRL[Serviço Controlador] - CA -->|Aplica config| HW - - HW -->|Métricas| TA - TA -->|Envia onchain| BC[Ledger DoubleZero] -``` - -| Agente | O Que Faz | -|-------|--------------| -| **Config Agent** | Busca configuração do controlador, aplica ao seu switch | -| **Telemetry Agent** | Mede latência/perda para outros dispositivos, reporta métricas onchain | - -### Passo 4.4: Instalar Config Agent - -#### Habilitar a API no seu switch - -Adicionar à configuração EOS: - -``` -management api eos-sdk-rpc - transport grpc eapilocal - localhost loopback vrf default - service all - no disabled -``` - -!!! note "Nota sobre VRF" - Substitua `default` pelo nome do seu VRF de gerenciamento se for diferente (por exemplo, `management`). - -#### Baixar e instalar o agente - -```bash -# Entrar no bash no switch -switch# bash -$ sudo bash -# cd /mnt/flash -# wget AGENT_DOWNLOAD_URL -# exit -$ exit - -# Instalar como extensão EOS -switch# copy flash:AGENT_FILENAME extension: -switch# extension AGENT_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Verificar a extensão - -```bash -switch# show extensions -``` - -O Status deve ser "A, I, B": - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -AGENT_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configurar e iniciar o agente - -Adicionar à configuração EOS: - -``` -daemon doublezero-agent - exec /usr/local/bin/doublezero-agent -pubkey - no shut -``` - -!!! note "Nota sobre VRF" - Se seu VRF de gerenciamento não for `default` (ou seja, o namespace não é `ns-default`), prefixe o comando exec com `exec /sbin/ip netns exec ns-`. Por exemplo, se seu VRF for `management`: - ``` - daemon doublezero-agent - exec /sbin/ip netns exec ns-management /usr/local/bin/doublezero-agent -pubkey - no shut - ``` - -Obtenha a pubkey do seu dispositivo com `doublezero device list` (coluna `account`). - -#### Verificar se está em execução - -```bash -switch# show agent doublezero-agent logs -``` - -Você deve ver "Starting doublezero-agent" e conexões bem-sucedidas ao controlador. - -### Passo 4.5: Instalar Telemetry Agent - -#### Copiar a chave do editor de métricas para o seu dispositivo - -```bash -scp ~/.config/doublezero/metrics-publisher.json :/mnt/flash/metrics-publisher-keypair.json -``` - -#### Registrar o editor de métricas onchain - -```bash -doublezero device update \ - --pubkey \ - --metrics-publisher -``` - -Obtenha a pubkey do seu arquivo metrics-publisher.json. - -#### Baixar e instalar o agente - -```bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget TELEMETRY_DOWNLOAD_URL -# exit -$ exit - -# Instalar como extensão EOS -switch# copy flash:TELEMETRY_FILENAME extension: -switch# extension TELEMETRY_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### Verificar a extensão - -```bash -switch# show extensions -``` - -O Status deve ser "A, I, B": - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -TELEMETRY_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### Configurar e iniciar o agente - -Adicionar à configuração EOS: - -``` -daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut -``` - -!!! note "Nota sobre VRF" - Se seu VRF de gerenciamento não for `default` (ou seja, o namespace não é `ns-default`), adicione `--management-namespace ns-` ao comando exec. Por exemplo, se seu VRF for `management`: - ``` - daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --management-namespace ns-management --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut - ``` - -#### Verificar se está em execução - -```bash -switch# show agent doublezero-telemetry logs -``` - -Você deve ver "Starting telemetry collector" e "Starting submission loop". - ---- - -## Fase 5: Rodagem do Link - -!!! warning "Todos os novos links devem passar por rodagem antes de transportar tráfego" - Novos links devem ser **drenados por pelo menos 24 horas** antes de serem ativados para tráfego de produção. Este requisito de rodagem é definido no [RFC12: Provisionamento de Rede](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md), que especifica ~200.000 slots do DZ Ledger (~20 horas) de métricas limpas antes que um link esteja pronto para serviço. - -Com os agentes instalados e em execução, monitore seus links em [metrics.doublezero.xyz](https://metrics.doublezero.xyz) por pelo menos 24 horas consecutivas: - -- Dashboard **"DoubleZero Device-Link Latencies"** — verifique **zero perda de pacotes** no link ao longo do tempo -- Dashboard **"DoubleZero Network Metrics"** — verifique **zero erros** nos seus links - -Remova o dreno do link apenas depois que o período de rodagem mostrar um link limpo com zero perda e zero erros. - ---- - -## Fase 6: Verificação & Ativação - -Percorra esta lista de verificação para confirmar que tudo está funcionando. - -!!! warning "Seu dispositivo começa bloqueado (`max_users = 0`)" - Quando um dispositivo é criado, `max_users` é definido como **0** por padrão. Isso significa que nenhum usuário pode se conectar a ele ainda. Isso é intencional — você deve verificar se tudo funciona antes de aceitar tráfego de usuários. - - **Antes de definir `max_users` acima de 0, você deve:** - - 1. Confirmar que todos os links completaram sua **rodagem de 24 horas** com zero perda/erros em [metrics.doublezero.xyz](https://metrics.doublezero.xyz) - 2. **Coordenar com DZ/Malbec Labs** para executar um teste de conectividade: - - Um usuário de teste pode se conectar ao seu dispositivo? - - O usuário recebe rotas pela rede DZ? - - O usuário pode rotear tráfego pela rede DZ de ponta a ponta? - 3. Somente após o DZ/ML confirmar que os testes passaram, defina max_users como 96: - - ```bash - doublezero device update --pubkey --max-users 96 - ``` - -### Verificações do Dispositivo - -```bash -# Seu dispositivo deve aparecer com status "activated" -doublezero device list | grep -``` - -**Saída esperada:** - -``` - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -```bash -# Suas interfaces devem estar listadas -doublezero device interface list | grep -``` - -**Saída esperada:** - -``` - nyc-dz001 | Loopback255 | loopback | vpnv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.91/32 | 56 | false | activated - nyc-dz001 | Loopback256 | loopback | ipv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.100/32 | 0 | false | activated - nyc-dz001 | Ethernet1/1 | physical | none | none | none | 0 | 0 | 1500 | static | 0 | | 0 | false | activated -``` - -### Verificações de Link - -```bash -# Os links devem mostrar status "activated" -doublezero link list | grep -``` - -**Saída esperada:** - -``` - 8vkYpXaBW8RuknJq... | nyc-lax-wan01 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -### Verificações de Agente - -No switch: - -```bash -# O config agent deve mostrar extrações de configuração bem-sucedidas -switch# show agent doublezero-agent logs | tail -20 - -# O telemetry agent deve mostrar envios bem-sucedidos -switch# show agent doublezero-telemetry logs | tail -20 -``` - -### Diagrama de Verificação Final - -```mermaid -flowchart TB - subgraph "Lista de Verificação" - D[Status do Dispositivo: activated?] - I[Interfaces: registradas?] - L[Links: activated?] - CA[Config Agent: buscando config?] - TA[Telemetry Agent: enviando métricas?] - end - - D --> PASS - I --> PASS - L --> PASS - CA --> PASS - TA --> PASS - - PASS[Todas as Verificações Passaram] --> NOTIFY[Notifique DZF/Malbec Labs
Você está tecnicamente pronto!] -``` - ---- - -## Resolução de Problemas - -### Criação de dispositivo falha - -- Verifique se sua chave de serviço está autorizada (`doublezero contributor list`) -- Verifique se os códigos de localização e exchange são válidos -- Certifique-se de que o prefixo DZ é um intervalo de IP público válido - -### Link preso em status "requested" - -- Links DZX requerem aceitação do outro contribuidor -- Entre em contato com eles para executar `doublezero link accept` - -### Config Agent não se conecta - -- Verifique se a rede de gerenciamento tem acesso à internet -- Verifique se a configuração do VRF corresponde à sua configuração -- Certifique-se de que a pubkey do dispositivo está correta - -### Telemetry Agent não envia - -- Verifique se a chave do editor de métricas está registrada onchain -- Verifique se o arquivo de keypair existe no switch -- Certifique-se de que a pubkey da conta do dispositivo está correta - ---- - -## Próximas Etapas - -- Revise o [Guia de Operações](contribute-operations.md) para atualizações de agentes e gerenciamento de links -- Consulte o [Glossário](glossary.md) para definições de termos -- Entre em contato com DZF/Malbec Labs se encontrar problemas + 203.0.113.2 \ No newline at end of file diff --git a/docs/contribute-provisioning.zh.md b/docs/contribute-provisioning.zh.md index a911204..3ced045 100644 --- a/docs/contribute-provisioning.zh.md +++ b/docs/contribute-provisioning.zh.md @@ -1,62 +1,102 @@ -# 设备配置指南 -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: 逐步指南：配置 DoubleZero 设备 (DZD) 并在链上注册其接口和角色。 +--- +# 设备配置指南 -本指南将引导您从头到尾完成DoubleZero设备（DZD）的配置。每个阶段与[入驻清单](contribute-overview.md#onboarding-checklist)相对应。 +本指南将带您从头到尾完成 DoubleZero 设备 (DZD) 的配置。每个阶段对应[上线清单](contribute-overview.md#onboarding-checklist)中的相应步骤。 --- ## 整体架构概览 -在深入步骤之前，先了解您正在构建的整体架构： +本指南将引导您在链上注册基础设施，以便 DoubleZero 网络能够通过您的设备路由流量。设备注册得越完整，它对网络的价值就越大。完整的链上设备表示能够实现更好的故障排查、容量规划，并让控制器做出更明智的决策。随着时间推移，目标是让控制器承担更多的配置责任。 + +### 核心概念 + +**接口** + +DZD 上的接口有多种形式：以太网端口、端口通道（由多个以太网端口组成的 LAG）和环回接口。每个在网络中发挥作用的接口都需要在链上注册，并设置适当的标志，以便协议了解其功能。 + +以太网端口和端口通道可以承担以下角色： + +| 标志 | 含义 | +|------|------| +| `--interface-dia dia` | 将接口标记为直接互联网接入上行链路 | +| `--interface-cyoa ` | 声明用户如何通过该接口建立 GRE 隧道（例如通过公共互联网、通过私有对等链路） | +| `--user-tunnel-endpoint true` | 该接口承载用户终止 GRE 隧道所用的公共 IP | + +用于 WAN 或 DZX 链路的接口不需要特定标志，只需注册其带宽，然后在创建链路时引用即可。 + +环回接口有多种用途： + +| 环回接口 | 含义 | +|----------|------| +| **Loopback100 / 101** | 承载用户终止 GRE 隧道所用的公共 IP。使用 `--user-tunnel-endpoint true` 注册。 | +| **Loopback255** (`vpnv4`) | 注册后控制器可以分配用于 BGP 路由器 ID、VPN-IPv4 对等（单播）、IS-IS 身份和段路由的 IP | +| **Loopback256** (`ipv4`) | 注册后控制器可以分配用于 IPv4 BGP 对等（组播）和 MSDP 会话的 IP | + +**链路** + +链路与接口分开注册，且接口必须先在链上存在，链路才能引用它们。创建 WAN 或 DZX 链路时，您需要指定一个已注册的接口作为链路的物理端点。并非所有接口都与链路关联：DIA、CYOA 和环回接口不连接到链路。 + +| 术语 | 含义 | +|------|------| +| **WAN 链路** | 您自己的两个 DZD 之间的链路 | +| **DZX 链路** | 您的 DZD 与另一个贡献者的 DZD 之间的链路 | + +### 架构概览 ```mermaid flowchart TB subgraph Onchain - SC[DoubleZero账本] + SC[DoubleZero 账本] end subgraph Your Infrastructure MGMT[管理服务器
DoubleZero CLI] - DZD[您的DZD
Arista交换机] - DZD ---|WAN链路| DZD2[您的其他DZD] + subgraph DZD[您的 DZD] + CYOA["DIA · CYOA 接口
(面向用户的上行链路)"] + WAN_INTF["WAN 链路接口"] + DZX_INTF["DZX 链路接口"] + LO100["Loopback100/101
(用户隧道端点)"] + end + DZD2[您的另一个 DZD] end subgraph Other Contributor - OtherDZD[他们的DZD] + OtherDZD[对方的 DZD] end - subgraph Users - VAL[验证器] - RPC[RPC节点] - end + USERS["用户"] MGMT -.->|注册设备、
链路、接口| SC - DZD ---|DZX链路| OtherDZD - VAL ---|通过互联网连接| DZD - RPC ---|通过互联网连接| DZD + WAN_INTF ---|WAN 链路| DZD2 + DZX_INTF ---|DZX 链路| OtherDZD + USERS -.|GRE 隧道|.-> CYOA + CYOA ---|路由至| LO100 ``` --- -## 阶段1：前提条件 +## 阶段 1：前提条件 -在配置设备之前，您需要完成物理硬件的安装并分配一些IP地址。 +在配置设备之前，您需要先完成物理硬件安装并分配一些 IP 地址。 -### 所需条件 +### 准备事项 -| 要求 | 用途 | +| 要求 | 原因 | |------|------| -| **DZD硬件** | Arista 7280CR3A交换机（参见[硬件规格](contribute.md#hardware-requirements)） | -| **机架空间** | 4U，需要适当的气流 | -| **电源** | 冗余供电，建议约4KW | -| **管理访问** | SSH/控制台访问以配置交换机 | -| **互联网连接** | 用于发布指标和从控制器获取配置 | -| **公共IPv4地址块** | DZ前缀池至少需要/29（参见下方） | +| **DZD 硬件** | Arista 7280CR3A 交换机（参见[硬件规格](contribute.md#hardware-requirements)） | +| **机柜空间** | 每个 DZD 需要 1U，确保良好的气流。参见[机柜与电源](contribute.md#rack-power-requirements) | +| **电源** | 两路独立供电，每路都能独立承担全部负载。参见[机柜与电源](contribute.md#rack-power-requirements) | +| **管理访问** | 通过 SSH/控制台访问来配置交换机 | +| **互联网连接** | 用于发布指标数据和从控制器获取配置 | +| **公共 IPv4 地址块** | DZ 前缀池至少需要 /29（见下文） | -### 安装DoubleZero CLI +### 安装 DoubleZero CLI -DoubleZero CLI（`doublezero`）在整个配置过程中用于注册设备、创建链路和管理您的贡献。应将其安装在**管理服务器或虚拟机**上——而不是DZD交换机本身。交换机只运行Config Agent和Telemetry Agent（在[阶段4](#phase-4-link-establishment-agent-installation)中安装）。 +DoubleZero CLI (`doublezero`) 在整个配置过程中用于注册设备、创建链路和管理您的贡献。它应安装在**管理服务器或虚拟机**上——而不是 DZD 交换机上。交换机只运行配置代理和遥测代理（在[阶段 4](#phase-4-link-establishment-agent-installation) 中安装）。 **Ubuntu / Debian：** ```bash @@ -75,61 +115,62 @@ sudo yum install doublezero sudo systemctl status doublezerod ``` -### 了解您的DZ前缀 +### 了解您的 DZ 前缀 -您的DZ前缀是DoubleZero协议管理用于IP分配的公共IP地址块。 +DZ 前缀是 DoubleZero 协议用于 IP 分配管理的一组公共 IP 地址。 ```mermaid flowchart LR - subgraph "您的/29地址块（8个IP）" - IP1["第一个IP
为您的设备
保留"] + subgraph "您的 /29 地址块（8 个 IP）" + IP1["第一个 IP
为您的设备
预留"] IP2["IP 2"] IP3["IP 3"] IP4["..."] IP8["IP 8"] end - IP1 -->|分配给| LO[DZD上的
Loopback100] - IP2 -->|分配给| U1[用户1] - IP3 -->|分配给| U2[用户2] + IP1 -->|分配给| LO[Loopback100
在您的 DZD 上] + IP2 -->|分配给| U1[用户 1] + IP3 -->|分配给| U2[用户 2] ``` -**DZ前缀的使用方式：** +**DZ 前缀的使用方式：** -- **第一个IP**：为您的设备保留（分配给Loopback100接口） -- **剩余IP**：分配给连接到您DZD的特定用户类型： - - `IBRLWithAllocatedIP`用户 - - `EdgeFiltering`用户 - - 多播发布者 -- **IBRL用户**：不消耗此池中的IP（他们使用自己的公共IP） +- **第一个 IP**：为您的设备预留（分配给 Loopback100 接口） +- **剩余 IP**：分配给连接到您 DZD 的特定用户类型： + - `IBRLWithAllocatedIP` 用户 + - `EdgeFiltering` 用户（未来用例） +- **IBRL 用户**：不消耗此池中的地址（他们使用自己的公共 IP） -!!! warning "DZ前缀规则" +!!! warning "DZ 前缀规则" **您不能将这些地址用于：** - 您自己的网络设备 - - DIA接口上的点对点链路 + - DIA 接口上的点对点链路 - 管理接口 - - DZ协议之外的任何基础设施 + - DZ 协议之外的任何基础设施 **要求：** - - 必须是**全球可路由（公共）**IPv4地址 - - 私有IP范围（10.x、172.16-31.x、192.168.x）会被智能合约拒绝 - - **最小大小：/29**（8个地址），建议使用更大的前缀（例如/28、/27） + - 必须是**全球可路由（公共）**的 IPv4 地址 + - 私有 IP 范围（10.x、172.16-31.x、192.168.x）会被智能合约拒绝 + - **最小大小：/29**（8 个地址），推荐更大的前缀（例如 /28、/27） - 整个地址块必须可用——不要预先分配任何地址 - 如果您需要为自己的设备（DIA接口IP、管理等）分配地址，请使用**单独的地址池**。 + 如果您需要为自己的设备分配地址（DIA 接口 IP、管理等），请使用**单独的地址池**。 --- -## 阶段2：账户设置 +## 阶段 2：账户设置 + +在此阶段，您将创建用于在网络上标识您和您设备的加密密钥，并指定奖励支付地址。 -在此阶段，您将创建在网络上标识您和您设备的加密密钥。 +此阶段将生成三个密钥：服务密钥、指标发布密钥和奖励管理密钥。请在[步骤 2.4](#step-24-submit-keys-to-dzf) 中将这三个密钥的公钥一并提交给 DZF。[奖励管理](contribute-rewards.md)详细介绍了奖励相关内容。 -### 在哪里运行CLI +### CLI 运行位置 -!!! warning "请勿在交换机上安装CLI" - DoubleZero CLI（`doublezero`）应安装在**管理服务器或虚拟机**上，而不是您的Arista交换机上。 +!!! warning "请勿在交换机上安装 CLI" + DoubleZero CLI (`doublezero`) 应安装在**管理服务器或虚拟机**上，而不是 Arista 交换机上。 ```mermaid flowchart LR @@ -138,9 +179,9 @@ flowchart LR KEYS[您的密钥对] end - subgraph "您的DZD交换机" - CA[Config Agent] - TA[Telemetry Agent] + subgraph "您的 DZD 交换机" + CA[配置代理] + TA[遥测代理] end CLI -->|创建设备、链路| BC[区块链] @@ -149,62 +190,83 @@ flowchart LR ``` | 安装在管理服务器上 | 安装在交换机上 | - |-------------------|--------------| - | `doublezero` CLI | Config Agent | - | 您的服务密钥 | Telemetry Agent | - | 您的指标发布者密钥 | 指标发布者密钥（副本） | + |--------------------|----------------| + | `doublezero` CLI | 配置代理 | + | 您的服务密钥对 | 遥测代理 | + | 您的指标发布密钥对 | 指标发布密钥对（副本） | ### 什么是密钥？ 可以将密钥理解为安全登录凭据： -- **服务密钥**：您的贡献者身份——用于运行CLI命令 -- **指标发布者密钥**：您设备用于提交遥测数据的身份 +- **服务密钥**：您的贡献者身份——用于运行 CLI 命令 +- **指标发布密钥**：您设备提交遥测数据的身份标识 +- **奖励管理密钥**：控制哪些钱包接收您的奖励——参见[奖励管理](contribute-rewards.md) -两者都是加密密钥对（您共享的公钥，您保密的私钥）。 +三者都是加密密钥对（一个用于共享的公钥和一个需要保密的私钥）。 ```mermaid flowchart LR subgraph "您的密钥" SK[服务密钥
~/.config/solana/id.json] - MK[指标发布者密钥
~/.config/doublezero/metrics-publisher.json] + MK[指标发布密钥
~/.config/doublezero/metrics-publisher.json] + RK[奖励管理密钥
离线保管] end - SK -->|用于| CLI[CLI命令
doublezero device create
doublezero link create] - MK -->|用于| TEL[Telemetry Agent
链上提交指标] + SK -->|用于| CLI[CLI 命令
doublezero device create
doublezero link create] + MK -->|用于| TEL[遥测代理
在链上提交指标] + RK -->|用于| REW[奖励门户
设置接收钱包] ``` -### 步骤2.1：生成服务密钥 +!!! note "单独保管奖励管理密钥" + 服务密钥和指标发布密钥存放在您的管理服务器和交换机上。奖励管理密钥控制您的资金去向，因此请将其存放在这些机器之外。只有在更改接收钱包时才需要使用它。 -这是您与DoubleZero交互的主要身份。 +### 步骤 2.1：生成您的服务密钥 + +这是您与 DoubleZero 交互的主要身份标识。 ```bash doublezero keygen ``` -这将在默认位置创建一个密钥对。输出显示您的**公钥**——这是您将与DZF共享的内容。 +这会在默认位置创建一个密钥对。输出会显示您的**公钥**——这是您需要与 DZF 共享的内容。 -### 步骤2.2：生成指标发布者密钥 +### 步骤 2.2：生成您的指标发布密钥 -此密钥由Telemetry Agent用于签署指标提交。 +此密钥由遥测代理用于签名指标提交。 ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### 步骤2.3：向DZF提交密钥 +### 步骤 2.3：创建您的奖励管理钱包 + +这是第三个密钥。它控制哪些钱包接收您的奖励，但它本身不持有奖励。 + +创建一个您能控制和签名的 Solana 钱包，然后充入约 0.01 SOL 以支付交易手续费。硬件钱包是一个不错的选择。不要重复使用您的服务密钥。 + +目前您只需要准备好钱包。在 DZF 注册此密钥后，您将在[步骤 2.7](#step-27-set-your-reward-recipients) 中设置实际接收奖励的钱包。 + +### 步骤 2.4：向 DZF 提交密钥 -联系DoubleZero基金会或Malbec Labs并提供： +联系 DoubleZero Foundation 或 Malbec Labs，提供以下信息： 1. 您的**服务密钥公钥** -2. 您的**GitHub用户名**（用于仓库访问） +2. 您的**奖励管理公钥**（来自步骤 2.3） +3. 您的 **GitHub 用户名**（用于获取仓库访问权限） + +请一并发送所有三项。DZF 会通过单独的链上交易注册服务密钥和奖励管理密钥，因此同时发送可以减少一次往返。 + +!!! danger "仅提供公钥" + 切勿向任何人发送私钥或密钥对文件，包括 DZF。DZF 只需要您的公钥。 他们将： - 在链上创建您的**贡献者账户** -- 授予对私有**贡献者仓库**的访问权限 +- 将您的**奖励管理密钥**与服务密钥关联注册 +- 授予您访问私有**贡献者仓库**的权限 -### 步骤2.4：验证您的账户 +### 步骤 2.5：验证您的账户 确认后，验证您的贡献者账户是否存在： @@ -214,68 +276,108 @@ doublezero contributor list 您应该在列表中看到您的贡献者代码。 -### 步骤2.5：访问贡献者仓库 +同时检查您的奖励管理密钥是否已注册： + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key -u mainnet-beta +``` + +`manager` 列应显示您的奖励管理公钥。如果为空，请要求 DZF 完成该步骤。 + +### 步骤 2.6：访问贡献者仓库 [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 仓库包含： - 基础设备配置 -- TCAM配置文件 -- ACL配置 -- 额外的安装说明 +- TCAM 配置文件 +- ACL 配置 +- 额外的设置说明 + +请按照其中的说明进行设备特定的配置。 + +### 步骤 2.7：设置您的奖励接收方 + +现在指定哪些钱包接收您的奖励，以及各自的比例。请在您的设备开始承载流量之前完成此操作。奖励从您的链路上线那一刻就开始累积，但在您指定接收钱包之前，协议无法进行支付。 -请按照其中的说明进行设备特定配置。 +使用您的奖励管理钱包登录 [doublezero.xyz/rewards](https://doublezero.xyz/rewards)，选择您的服务密钥，然后输入每个接收钱包及其百分比。百分比之和必须为 100。 + +!!! warning "每个接收方都需要 2Z 代币账户" + 协议通过普通代币转账发送 2Z，不会为您创建代币账户。如果接收钱包没有 2Z 代币账户，会导致该纪元的支付失败。 + +参见[奖励管理](contribute-rewards.md)获取完整操作指南，包括 CLI 替代方式、如何检查代币账户以及如何验证结果。 --- -## 阶段3：设备配置 +## 阶段 3：设备配置 -现在您将在区块链上注册物理设备并配置其接口。 +现在您将在区块链上注册您的物理设备并配置其接口。 ### 了解设备类型 +**边缘设备（Edge）** — 仅接受用户连接 + ```mermaid -flowchart TB - subgraph "边缘设备" - E[边缘DZD] - EU[用户连接到此处] - EU --> E - E <-->|DZX链路| ED[其他DZD] +flowchart LR + subgraph EDZD[边缘 DZD] + E_CYOA["DIA · CYOA 接口"] + E_TUN["Loopback100/101 + (用户隧道端点)"] + E_DZX["DZX 链路接口"] + E_CYOA --- E_TUN end + EU["用户"] -.|GRE 隧道|.-> E_CYOA + E_DZX <-->|DZX 链路| ED["DZD（不同贡献者）"] +``` + +**中转设备（Transit）** — 在设备间转发流量，无用户连接 - subgraph "传输设备" - T[传输DZD] - T <-->|WAN链路| T2[另一个DZD] - T <-->|DZX链路| TD[其他DZD] +```mermaid +flowchart LR + subgraph TDZD[中转 DZD] + T_WAN["WAN 链路接口"] + T_DZX["DZX 链路接口"] end + T_WAN <-->|WAN 链路| T2["DZD（同一贡献者）"] + T_DZX <-->|DZX 链路| TD["DZD（不同贡献者）"] +``` + +**混合设备（Hybrid）** — 用户连接和骨干传输兼备，最常见 - subgraph "混合设备" - H[混合DZD] - HU[用户连接到此处] - HU --> H - H <-->|WAN链路| H2[另一个DZD] - H <-->|DZX链路| HD[其他DZD] +```mermaid +flowchart LR + subgraph HDZD[混合 DZD] + H_CYOA["DIA · CYOA 接口"] + H_TUN["Loopback100/101 + (用户隧道端点)"] + H_WAN["WAN 链路接口"] + H_DZX["DZX 链路接口"] + H_CYOA --- H_TUN end + HU["用户"] -.|GRE 隧道|.-> H_CYOA + H_WAN <-->|WAN 链路| H2["DZD（同一贡献者）"] + H_DZX <-->|DZX 链路| HD["DZD（不同贡献者）"] ``` -| 类型 | 功能 | 使用时机 | -|------|------|---------| -| **边缘** | 仅接受用户连接 | 单一位置，仅面向用户 | -| **传输** | 在设备之间传输流量 | 骨干连接，无用户 | -| **混合** | 同时支持用户连接和骨干 | 最常见——功能全面 | +| 类型 | 功能 | 适用场景 | +|------|------|----------| +| **边缘（Edge）** | 仅接受用户连接 | 单一位置，仅面向用户 | +| **中转（Transit）** | 在设备间转发流量 | 骨干连接，无用户 | +| **混合（Hybrid）** | 兼具用户连接和骨干功能 | 最常见——全能型 | -### 步骤3.1：查找您的位置和交换中心 +### 步骤 3.1：查找您的位置和交换点 -在创建设备之前，查找您的数据中心位置和最近交换中心的代码： +在创建设备之前，查找您的数据中心位置和最近交换点的代码： ```bash # 列出可用位置（数据中心） doublezero location list -# 列出可用交换中心（互连点） +# 列出可用交换点（互联点） doublezero exchange list ``` -### 步骤3.2：在链上创建您的设备 +### 步骤 3.2：在链上创建您的设备 在区块链上注册您的设备： @@ -319,39 +421,46 @@ doublezero device list | grep nyc-dz001 | 参数 | 含义 | |------|------| -| `--code` | 您设备的唯一名称（例如，`nyc-dz001`） | -| `--contributor` | 您的贡献者代码（由DZF提供） | -| `--device-type` | `hybrid`、`transit`或`edge` | -| `--location` | 来自`location list`的数据中心代码 | -| `--exchange` | 来自`exchange list`的最近交换中心代码 | -| `--public-ip` | 用户通过互联网连接到您设备的公共IP | -| `--dz-prefixes` | 分配给用户的IP地址块 | +| `--code` | 您设备的唯一名称（例如 `nyc-dz001`） | +| `--contributor` | 您的贡献者代码（由 DZF 提供） | +| `--device-type` | `hybrid`、`transit` 或 `edge` | +| `--location` | 从 `location list` 获取的数据中心代码 | +| `--exchange` | 从 `exchange list` 获取的最近交换点代码 | +| `--public-ip` | 用户通过互联网连接到您设备的公共 IP | +| `--dz-prefixes` | 为用户分配的 IP 地址块 | -### 步骤3.3：创建必需的环回接口 +### 步骤 3.3：创建必需的环回接口 -每个设备需要两个环回接口用于内部路由： +每个设备都需要两个用于内部路由的环回接口： ```bash -# VPNv4环回 +# VPNv4 环回 doublezero device interface create Loopback255 --loopback-type vpnv4 -# IPv4环回 +# IPv4 环回 doublezero device interface create Loopback256 --loopback-type ipv4 ``` -**预期输出（每个命令）：** +**预期输出（每条命令）：** ``` Signature: 3mNx9K...truncated...8wRt5 ``` -### 步骤3.4：创建物理接口 +### 步骤 3.4：创建物理接口 -注册您将使用的物理端口： +注册将用于 WAN 或 DZX 链路的物理接口。这些接口必须先在链上存在，然后才能创建引用它们的链路。在此步骤中，您只需注册接口及其带宽，链路将在后续步骤中创建。 ```bash -# 基础接口 -doublezero device interface create Ethernet1/1 +doublezero device interface create \ + --bandwidth +``` + +**示例：** + +```bash +doublezero device interface create nyc-dz001 Ethernet1/1 \ + --bandwidth 10Gbps ``` **预期输出：** @@ -360,34 +469,36 @@ doublezero device interface create Ethernet1/1 Signature: 7pQw2R...truncated...4xKm9 ``` -### 步骤3.5：创建CYOA接口（用于边缘/混合设备） +对每个将用作 WAN 或 DZX 链路端点的接口重复此操作。CYOA 和 DIA 接口将在下一步骤中单独注册。 + +### 步骤 3.5：创建 CYOA 接口（适用于边缘/混合设备） -混合型和边缘型DZD需要**两个公共IP地址**，用户在这些地址上终止其GRE隧道。用户可以通过单播、多播或两者连接，哪个IP用于哪个目的会按用户轮换。 +混合和边缘 DZD 需要**两个公共 IP 地址**供用户终止其 GRE 隧道。用户可以通过单播、组播或两者同时连接，哪个 IP 服务于哪个用途会按用户轮换。 -两个IP都必须使用`--user-tunnel-endpoint true`注册，可以在物理接口或环回接口上。这包括您在设备创建时提供的IP；该IP仍需在此处明确注册。 +两个 IP 都必须以 `--user-tunnel-endpoint true` 注册，可以在物理接口或环回接口上。这包括您在设备创建时提供的 IP——该 IP 仍需在此处显式注册。 -如果您受IP约束，可以使用DZ前缀的第一个`/32`作为两个IP之一。 +如果您的 IP 资源紧张，可以使用 DZ 前缀的第一个 `/32` 作为两个 IP 之一。 -#### CYOA和DIA +#### CYOA 和 DIA | 类型 | 标志 | 用途 | |------|------|------| -| DIA | `--interface-dia dia` | 将端口标记为直接互联网访问 | -| CYOA | `--interface-cyoa <子类型>` | 声明用户如何将GRE隧道连接到您的设备 | +| DIA | `--interface-dia dia` | 将端口标记为直接互联网接入 | +| CYOA | `--interface-cyoa ` | 声明用户如何将 GRE 隧道连接到您的设备 | -CYOA标志始终设置在**物理接口**（以太网端口或端口聚合）上，从不设置在环回接口上。 +CYOA 标志始终设置在**物理接口**（以太网端口或端口通道）上，不能设置在环回接口上。 -| CYOA子类型 | 使用场景 | -|-----------|---------| +| CYOA 子类型 | 使用场景 | +|-------------|----------| | `gre-over-dia` | 用户通过公共互联网连接。最常见。 | -| `gre-over-private-peering` | 用户通过直接交叉连接或私有电路连接 | -| `gre-over-public-peering` | 用户在互联网交换点(IX)与您对等 | -| `gre-over-fabric` | 用户共同托管并通过本地网络结构连接 | -| `gre-over-cable` | 直接电缆连接到单个专用用户 | +| `gre-over-private-peering` | 用户通过直连交叉连接或专用线路连接 | +| `gre-over-public-peering` | 用户在互联网交换中心 (IX) 与您对等 | +| `gre-over-fabric` | 用户同地部署，通过本地交换网络连接 | +| `gre-over-cable` | 直接线缆连接到单个专用用户 | -#### 场景A：单物理接口 +#### 场景 A：单物理接口 -到ISP的一个物理上行链路。Ethernet1/1是CYOA和DIA接口，承载两个公共IP之一。Loopback100承载第二个公共IP。 +一条连接到 ISP 的物理上行链路。Ethernet1/1 是 CYOA 和 DIA 接口，承载两个公共 IP 之一。Loopback100 承载第二个公共 IP。 ```mermaid flowchart LR @@ -396,26 +507,26 @@ flowchart LR subgraph DZD["DZD"] E1["Eth1/1 203.0.113.1/30 - CYOA · DIA · user tunnel endpoint"] + CYOA · DIA · 用户隧道端点"] LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n 用户隧道端点"] E1 --- LO end - ISP["ISP路由器 + ISP["ISP 路由器 203.0.113.2/30"] ISP -- "10GbE" --- E1 - USERS -. "GRE隧道" .-> E1 - USERS -. "GRE隧道" .-> LO + USERS -. "GRE 隧道" .-> E1 + USERS -. "GRE 隧道" .-> LO ``` | 接口 | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | 贡献者分配的IP/子网 | 端口速度 | 承诺速率 | `bgp`或`static` | `true` | -| Loopback100 | — | — | 您的公共/32 | `0bps` | — | — | `true` | +| Ethernet1/1 | `gre-over-dia` | `dia` | 贡献者分配的 IP/子网 | 端口速率 | 承诺速率 | `bgp` 或 `static` | `true` | +| Loopback100 | — | — | 您的公共 /32 | `0bps` | — | — | `true` | -场景A的示例命令： +基于场景 A 执行的命令示例： ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -432,9 +543,9 @@ doublezero device interface create mydzd-nyc01 Loopback100 \ --user-tunnel-endpoint true ``` -#### 场景B：端口聚合（LAG） +#### 场景 B：端口通道（LAG） -DZD通过带有IP的端口聚合连接到上游设备。端口聚合承载一个公共IP并是CYOA端点。Loopback100承载第二个公共IP。 +DZD 通过带有 IP 的端口通道连接到上游设备。端口通道承载一个公共 IP，作为 CYOA 端点。Loopback100 承载第二个公共 IP。 ```mermaid flowchart LR @@ -446,567 +557,21 @@ flowchart LR end subgraph DZD["DZD"] - subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · user tunnel endpoint"] + subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · 用户隧道端点"] E1["Eth1/1"] E2["Eth2/1"] end LO["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] + 198.51.100.1/32\n 用户隧道端点"] PC --- LO end SWPC -- "2x 10GbE" --- PC - USERS -. "GRE隧道" .-> PC - USERS -. "GRE隧道" .-> LO + USERS -. "GRE 隧道" .-> PC + USERS -. "GRE 隧道" .-> LO ``` | 接口 | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | 贡献者分配的IP/子网 | 组合LAG速度 | 承诺速率 | `bgp`或`static` | `true` | -| Loopback100 | — | — | 您的公共/32 | `0bps` | — | — | `true` | - -场景B的示例命令： -```bash -doublezero device interface create mydzd-fra01 Port-Channel1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 20Gbps \ - --cir 2Gbps \ - --routing-mode bgp \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-fra01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -#### 场景C：到独立路由器的双物理上行链路 - -每个物理接口连接到不同的上游路由器。两个公共IP位于Loopback100和Loopback101上，均注册为用户隧道端点。 - -```mermaid -flowchart LR - USERS(["终端用户"]) - - RA["路由器A - 203.0.113.2/30"] - RB["路由器B - 203.0.113.6/30"] - - subgraph DZD["DZD"] - E1["Eth1/1 - 203.0.113.1/30 - CYOA · DIA"] - E2["Eth2/1 - 203.0.113.5/30 - CYOA · DIA"] - LO0["Loopback100 - 198.51.100.1/32\n user tunnel endpoint"] - LO1["Loopback101 - 198.51.100.2/32\n user tunnel endpoint"] - E1 --> LO0 - E2 --> LO1 - end - - RA -- "10GbE" --- E1 - RB -- "10GbE" --- E2 - USERS -. "GRE隧道" .-> LO0 - USERS -. "GRE隧道" .-> LO1 -``` - -| 接口 | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | 贡献者分配的IP/子网 | 端口速度 | 承诺速率 | `bgp`或`static` | — | -| Ethernet2/1 | `gre-over-dia` | `dia` | 贡献者分配的IP/子网 | 端口速度 | 承诺速率 | `bgp`或`static` | — | -| Loopback100 | — | — | 您的公共/32 | `0bps` | — | — | `true` | -| Loopback101 | — | — | 您的公共/32 | `0bps` | — | — | `true` | - -场景C的示例命令： -```bash -doublezero device interface create mydzd-ams01 Ethernet1/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.1/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Ethernet2/1 \ - --interface-cyoa gre-over-dia \ - --interface-dia dia \ - --ip-net 203.0.113.5/30 \ - --bandwidth 10Gbps \ - --cir 1Gbps \ - --routing-mode bgp - -doublezero device interface create mydzd-ams01 Loopback100 \ - --ip-net 198.51.100.1/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true - -doublezero device interface create mydzd-ams01 Loopback101 \ - --ip-net 198.51.100.2/32 \ - --bandwidth 0bps \ - --user-tunnel-endpoint true -``` - -### 步骤3.6：验证您的设备 - -```bash -doublezero device list -``` - -**示例输出：** - -``` - account | code | contributor | location | exchange | device_type | public_ip | dz_prefixes | users | max_users | status | health | mgmt_vrf | owner - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -您的设备应显示状态`activated`。 - ---- - -## 阶段4：链路建立与代理安装 - -链路将您的设备连接到DoubleZero网络的其余部分。 - -### 了解链路 - -```mermaid -flowchart LR - subgraph "您的网络" - D1[您的DZD 1
NYC] - D2[您的DZD 2
LAX] - end - - subgraph "其他贡献者" - O1[他们的DZD
NYC] - end - - D1 ---|WAN链路
同一贡献者| D2 - D1 ---|DZX链路
不同贡献者| O1 -``` - -| 链路类型 | 连接对象 | 接受方式 | -|---------|---------|---------| -| **WAN链路** | 您的两个设备 | 自动（您拥有两端） | -| **DZX链路** | 您的设备与另一个贡献者 | 需要对方接受 | - -### 步骤4.1：创建WAN链路（如果您有多个设备） - -WAN链路连接您自己的设备： - -```bash -doublezero link create wan \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --side-z-interface \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 20 \ - --jitter-ms 1 -``` - -**示例：** - -```bash -doublezero link create wan \ - --code nyc-lax-wan01 \ - --contributor acme \ - --side-a nyc-dz001 \ - --side-a-interface Ethernet3/1 \ - --side-z lax-dz001 \ - --side-z-interface Ethernet3/1 \ - --bandwidth 10000 \ - --mtu 9000 \ - --delay-ms 65 \ - --jitter-ms 1 -``` - -**预期输出：** - -``` -Signature: 5tNm7K...truncated...9pRw2 -``` - -### 步骤4.2：创建DZX链路 - -DZX链路将您的设备直接连接到另一个贡献者的DZD： - -```bash -doublezero link create dzx \ - --code \ - --contributor \ - --side-a \ - --side-a-interface \ - --side-z \ - --bandwidth \ - --mtu \ - --delay-ms \ - --jitter-ms -``` - -**预期输出：** - -``` -Signature: 8mKp3W...truncated...2nRx7 -``` - -创建DZX链路后，另一个贡献者必须接受它： - -```bash -# 另一个贡献者运行此命令 -doublezero link accept \ - --code \ - --side-z-interface -``` - -**预期输出（接受方贡献者）：** - -``` -Signature: 6vQt9L...truncated...3wPm4 -``` - -### 步骤4.3：验证链路 - -```bash -doublezero link list -``` - -**示例输出：** - -``` - account | code | contributor | side_a_name | side_a_iface_name | side_z_name | side_z_iface_name | link_type | bandwidth | mtu | delay_ms | jitter_ms | delay_override_ms | tunnel_id | tunnel_net | status | health | owner - 8vkYpXaBW8RuknJq... | nyc-dz001:lax-dz001 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -一旦两端都配置完成，链路应显示状态`activated`。 - ---- - -### 代理安装 - -两个软件代理在您的DZD上运行： - -```mermaid -flowchart TB - subgraph "您的DZD" - CA[Config Agent] - TA[Telemetry Agent] - HW[交换机硬件/软件] - end - - CA -->|轮询配置| CTRL[控制器服务] - CA -->|应用配置| HW - - HW -->|指标| TA - TA -->|链上提交| BC[DoubleZero账本] -``` - -| 代理 | 功能 | -|------|------| -| **Config Agent** | 从控制器拉取配置，应用到您的交换机 | -| **Telemetry Agent** | 测量到其他设备的延迟/丢包，链上报告指标 | - -### 步骤4.4：安装Config Agent - -#### 在交换机上启用API - -添加到EOS配置： - -``` -management api eos-sdk-rpc - transport grpc eapilocal - localhost loopback vrf default - service all - no disabled -``` - -!!! note "VRF注意事项" - 如果您的管理VRF名称不同（例如`management`），请将`default`替换为您的管理VRF名称。 - -#### 下载并安装代理 - -```bash -# 在交换机上进入bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget AGENT_DOWNLOAD_URL -# exit -$ exit - -# 安装为EOS扩展 -switch# copy flash:AGENT_FILENAME extension: -switch# extension AGENT_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### 验证扩展 - -```bash -switch# show extensions -``` - -状态应为"A, I, B"： - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -AGENT_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### 配置并启动代理 - -添加到EOS配置： - -``` -daemon doublezero-agent - exec /usr/local/bin/doublezero-agent -pubkey - no shut -``` - -!!! note "VRF注意事项" - 如果您的管理VRF不是`default`（即命名空间不是`ns-default`），请在exec命令前加上`exec /sbin/ip netns exec ns-`。例如，如果您的VRF是`management`： - ``` - daemon doublezero-agent - exec /sbin/ip netns exec ns-management /usr/local/bin/doublezero-agent -pubkey - no shut - ``` - -从`doublezero device list`获取您的设备公钥（`account`列）。 - -#### 验证是否正在运行 - -```bash -switch# show agent doublezero-agent logs -``` - -您应该看到"Starting doublezero-agent"以及成功的控制器连接。 - -### 步骤4.5：安装Telemetry Agent - -#### 将指标发布者密钥复制到设备 - -```bash -scp ~/.config/doublezero/metrics-publisher.json :/mnt/flash/metrics-publisher-keypair.json -``` - -#### 在链上注册指标发布者 - -```bash -doublezero device update \ - --pubkey \ - --metrics-publisher -``` - -从您的metrics-publisher.json文件获取公钥。 - -#### 下载并安装代理 - -```bash -switch# bash -$ sudo bash -# cd /mnt/flash -# wget TELEMETRY_DOWNLOAD_URL -# exit -$ exit - -# 安装为EOS扩展 -switch# copy flash:TELEMETRY_FILENAME extension: -switch# extension TELEMETRY_FILENAME -switch# copy installed-extensions boot-extensions -``` - -#### 验证扩展 - -```bash -switch# show extensions -``` - -状态应为"A, I, B"： - -``` -Name Version/Release Status Extension -------------------------------------------- ------------------- ---------- --------- -TELEMETRY_FILENAME MAINNET_CLIENT_VERSION/1 A, I, B 1 - -A: available | NA: not available | I: installed | F: forced | B: install at boot -``` - -#### 配置并启动代理 - -添加到EOS配置： - -``` -daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut -``` - -!!! note "VRF注意事项" - 如果您的管理VRF不是`default`（即命名空间不是`ns-default`），请在exec命令中添加`--management-namespace ns-`。例如，如果您的VRF是`management`： - ``` - daemon doublezero-telemetry - exec /usr/local/bin/doublezero-telemetry --management-namespace ns-management --local-device-pubkey --env mainnet --keypair /mnt/flash/metrics-publisher-keypair.json - no shut - ``` - -#### 验证是否正在运行 - -```bash -switch# show agent doublezero-telemetry logs -``` - -您应该看到"Starting telemetry collector"和"Starting submission loop"。 - ---- - -## 阶段5：链路磨合 - -!!! warning "所有新链路在承载流量前必须完成磨合" - 新链路必须**至少排水24小时**，然后才能激活用于生产流量。此磨合要求在[RFC12：网络配置](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md)中定义，规定链路就绪前需要约200,000个DZ账本槽位（约20小时）的干净指标。 - -在代理安装并运行后，在[metrics.doublezero.xyz](https://metrics.doublezero.xyz)上监控您的链路至少连续24小时： - -- **"DoubleZero Device-Link Latencies"**仪表板——验证链路上随时间**零丢包** -- **"DoubleZero Network Metrics"**仪表板——验证链路上**零错误** - -只有当磨合期显示干净的链路（零丢包和零错误）时，才能解除排水状态。 - ---- - -## 阶段6：验证与激活 - -通过此清单确认一切正常工作。 - -!!! warning "您的设备初始锁定（`max_users = 0`）" - 创建设备时，`max_users`默认设置为**0**。这意味着还没有用户可以连接到它。这是有意为之——您必须在接受用户流量之前验证一切正常。 - - **在将`max_users`设置为0以上之前，您必须：** - - 1. 确认所有链路已在[metrics.doublezero.xyz](https://metrics.doublezero.xyz)上完成**24小时磨合**，零丢包/错误 - 2. **与DZ/Malbec Labs协调**进行连接测试： - - 测试用户能否连接到您的设备？ - - 用户是否通过DZ网络接收路由？ - - 用户是否能端到端通过DZ网络路由流量？ - 3. 仅在DZ/ML确认测试通过后，将max_users设置为96： - - ```bash - doublezero device update --pubkey --max-users 96 - ``` - -### 设备检查 - -```bash -# 您的设备应显示状态"activated" -doublezero device list | grep -``` - -**预期输出：** - -``` - 7xKm9pQw2R4vHt3... | nyc-dz001 | acme | EQX-NY5 | nyc | hybrid | 203.0.113.10 | 198.51.100.0/28 | 0 | 14 | activated | pending | | 5FMtd5Woq5XAAg54... -``` - -```bash -# 您的接口应被列出 -doublezero device interface list | grep -``` - -**预期输出：** - -``` - nyc-dz001 | Loopback255 | loopback | vpnv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.91/32 | 56 | false | activated - nyc-dz001 | Loopback256 | loopback | ipv4 | none | none | 0 | 0 | 1500 | static | 0 | 172.16.1.100/32 | 0 | false | activated - nyc-dz001 | Ethernet1/1 | physical | none | none | none | 0 | 0 | 1500 | static | 0 | | 0 | false | activated -``` - -### 链路检查 - -```bash -# 链路应显示状态"activated" -doublezero link list | grep -``` - -**预期输出：** - -``` - 8vkYpXaBW8RuknJq... | nyc-lax-wan01 | acme | nyc-dz001 | Ethernet3/1 | lax-dz001 | Ethernet3/1 | WAN | 10Gbps | 9000 | 65.00ms | 1.00ms | 0.00ms | 42 | 172.16.0.84/31 | activated | pending | 5FMtd5Woq5XAAg54... -``` - -### 代理检查 - -在交换机上： - -```bash -# Config Agent应显示成功的配置拉取 -switch# show agent doublezero-agent logs | tail -20 - -# Telemetry Agent应显示成功的提交 -switch# show agent doublezero-telemetry logs | tail -20 -``` - -### 最终验证图 - -```mermaid -flowchart TB - subgraph "验证清单" - D[设备状态：已激活？] - I[接口：已注册？] - L[链路：已激活？] - CA[Config Agent：正在拉取配置？] - TA[Telemetry Agent：正在提交指标？] - end - - D --> PASS - I --> PASS - L --> PASS - CA --> PASS - TA --> PASS - - PASS[所有检查通过] --> NOTIFY[通知DZF/Malbec Labs
您在技术上已准备就绪！] -``` - ---- - -## 故障排除 - -### 设备创建失败 - -- 验证您的服务密钥已获授权（`doublezero contributor list`） -- 检查位置和交换中心代码是否有效 -- 确保DZ前缀是有效的公共IP范围 - -### 链路卡在"requested"状态 - -- DZX链路需要另一个贡献者的接受 -- 联系他们运行`doublezero link accept` - -### Config Agent无法连接 - -- 验证管理网络有互联网访问 -- 检查VRF配置是否与您的设置匹配 -- 确保设备公钥正确 - -### Telemetry Agent未提交 - -- 验证指标发布者密钥已在链上注册 -- 检查密钥文件是否存在于交换机上 -- 确保设备账户公钥正确 - ---- - -## 后续步骤 - -- 查阅[运营指南](contribute-operations.md)了解代理升级和链路管理 -- 在[词汇表](glossary.md)中查看术语定义 -- 如遇问题，请联系DZF/Malbec Labs +| Port-Channel1 | `gre-over-dia` | `dia` | 贡献者分配的 IP/子网 | LAG 组合速率 | 承诺速率 | `bgp` 或 `static` | `true` | +| Loopback100 | — | — \ No newline at end of file diff --git a/docs/contribute-rewards.es.md b/docs/contribute-rewards.es.md new file mode 100644 index 0000000..f290cf9 --- /dev/null +++ b/docs/contribute-rewards.es.md @@ -0,0 +1,292 @@ +--- +description: Configura la gestión de recompensas para que las recompensas en 2Z obtenidas por tu contribución a DoubleZero se paguen a las billeteras que tú controlas. +--- + +# Gestión de Recompensas + +Ganas recompensas en [2Z](glossary.md#2z-token) por el ancho de banda y los dispositivos que contribuyes. El protocolo paga esas recompensas por sí mismo, directamente a las billeteras que tú designes. Hasta que las designes, no se puede realizar ningún pago. + +!!! warning "Haz esto durante la configuración de la cuenta" + Configura la gestión de recompensas en la [Fase 2: Configuración de la Cuenta](contribute-provisioning.md#phase-2-account-setup), antes de que tu dispositivo transporte tráfico. + + Tus recompensas siguen acumulándose si dejas esto para después. El protocolo no las quema y no expiran. Lo que pierdes es el pago automático: el proceso de pago rutinario trabaja con las épocas recientes, por lo que cualquier época que pase mientras no tengas destinatarios configurados tiene que pagarse manualmente después. Consulta [Si Configuras Esto Tarde](#si-configuras-esto-tarde). + +--- + +## Cómo Funciona + +Están involucradas tres claves. Cada una hace un trabajo diferente, y es más seguro mantenerlas separadas. + +| Clave | Qué hace | ¿Recibe recompensas? | +|-------|----------|----------------------| +| **Clave de servicio** | Te identifica como contribuidor y firma tus comandos CLI. También nombra tu cuenta de recompensas onchain. | No | +| **Clave del gestor de recompensas** | Firma los cambios en la lista de billeteras que reciben recompensas. | No | +| **Billetera(s) destinataria(s)** | Almacena los 2Z que el protocolo te envía. Hasta 8 billeteras. | Sí | + +La DoubleZero Foundation registra tu clave del gestor de recompensas contra tu clave de servicio. Solo DZF puede hacer eso. Después de eso, solo tu clave del gestor de recompensas puede cambiar la lista de destinatarios, y DZF no puede redirigir tus recompensas. + +```mermaid +flowchart LR + DZF["DZF"] -->|"Registra tu
clave del gestor de recompensas"| ACC["Tu cuenta de recompensas
onchain"] + RM["Clave del gestor de recompensas
(tú la conservas, mantenla offline)"] -->|"Establece destinatarios
y porcentajes"| ACC + ACC --> R1["Billetera destinataria 1"] + ACC --> R2["Billetera destinataria 2"] + PROTO["El protocolo paga
cada época DZ"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## Qué Necesitas Primero + +- Una cuenta de contribuidor onchain. Verifica con `doublezero contributor list`. +- Una billetera Solana para actuar como tu gestor de recompensas, con aproximadamente 0.01 SOL para pagar las comisiones de transacción. +- Una o más billeteras para recibir los 2Z. +- El CLI `doublezero-solana`, si quieres usar la línea de comandos en lugar del portal. Instálalo con `sudo apt update && sudo apt install doublezero-solana`. + +!!! tip "Usa una billetera de hardware para la clave del gestor de recompensas" + La clave del gestor de recompensas controla hacia dónde va tu dinero. Mantenla en una billetera de hardware o de otro modo offline. Nunca necesita estar en un servidor, y nunca almacena tus recompensas. + +--- + +## Paso 1: Crea Tu Billetera del Gestor de Recompensas + +Crea una billetera Solana que controles y con la que puedas firmar. Puede ser una billetera de hardware, una billetera de navegador o un archivo de par de claves. + +Fondéala con una pequeña cantidad de SOL, aproximadamente 0.01 SOL. Esto solo paga las comisiones de red cuando cambias tu lista de destinatarios. + +No reutilices tu clave de servicio para esto. Si la clave de servicio está en un servidor de gestión, cualquiera que acceda a ese servidor podría redirigir tus recompensas. + +--- + +## Paso 2: Envía la Clave Pública a DZF + +Entrega a DZF la **clave pública** de tu billetera del gestor de recompensas. Nunca compartas la clave privada. + +DZF la registra contra tu clave de servicio onchain y confirma cuando está hecho. No puedes hacer este paso tú mismo. + +!!! tip "Envíala junto con tu clave de servicio" + Si estás siguiendo la [Guía de Aprovisionamiento de Dispositivos](contribute-provisioning.md), envía esta clave pública al mismo tiempo que tu clave de servicio y nombre de usuario de GitHub, en el [Paso 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). DZF registra las dos claves en transacciones separadas, así que enviarlas juntas ahorra un ida y vuelta. + +Puedes verificar que se registró: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +La columna `manager` muestra tu clave del gestor de recompensas. Si está vacía, DZF aún no la ha registrado. + +--- + +## Paso 3: Configura Tus Billeteras Destinatarias + +Ahora indica a dónde deben ir las recompensas. Puedes usar el portal web o el CLI. Ambos escriben lo mismo onchain. + +Reglas que aplican en cualquier caso: + +- Como máximo 8 billeteras destinatarias. +- Los porcentajes deben ser números enteros y deben sumar exactamente 100. +- Un destinatario no puede tener una participación del 0%. Elimínalo en su lugar. + +!!! info "Si tu acuerdo con DZF incluye una distribución de ingresos" + Algunos contribuidores tienen un acuerdo que divide las recompensas con la fundación, por ejemplo cuando DZF proporcionó el hardware. Si eso aplica para ti, DZF te da la dirección y el porcentaje que debes ingresar aquí. Pregunta a DZF si no estás seguro. + +=== "Portal web" + + 1. Ve a [doublezero.xyz/rewards](https://doublezero.xyz/rewards). La dirección anterior, `rewards.doublezero.xyz`, redirige aquí. + 2. Conecta tu billetera del gestor de recompensas con el botón de billetera en la esquina superior derecha. + 3. Selecciona tu clave de servicio de la lista en la siguiente página. + 4. Ingresa cada dirección de billetera destinataria y su porcentaje. El total debe ser 100%. + 5. Haz clic en **Submit** y aprueba la transacción en tu billetera. + +=== "CLI" + + Ejecuta esto con tu par de claves del gestor de recompensas como `-k`. Repite `--recipient` para cada billetera. + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | Flag | Descripción | + |------|-------------| + | `--service-key` | Tu clave de servicio de contribuidor. Nombra la cuenta de recompensas onchain. | + | `--recipient` | Un destinatario en el formato `PUBKEY:PERCENT`. Números enteros, de 1 a 100, que sumen 100. Máximo 8. | + | `-k` | Tu par de claves del gestor de recompensas. La transacción falla si este no es el gestor de recompensas registrado. | + | `-u` | `mainnet-beta`. | + + Agrega `--dry-run` primero si quieres simular la transacción sin enviarla. + +--- + +## Paso 4: Verifica Que Cada Destinatario Pueda Recibir 2Z + +El protocolo envía 2Z con una transferencia de tokens simple. **No** crea la cuenta de tokens por ti. Si una billetera destinataria no tiene una cuenta de tokens 2Z, el pago de esa época falla. + +El mint de 2Z en mainnet es: + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +Lista las cuentas de tokens que una billetera ya tiene: + +```bash +spl-token accounts --owner -u m +``` + +Si `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` no aparece en esa lista, crea la cuenta una vez: + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +Cualquier billetera con fondos puede pagar esto. Cuesta una pequeña cantidad de SOL y solo necesita hacerse una vez por billetera destinataria. + +!!! note "Las billeteras que ya tienen 2Z están bien" + Si la billetera ha recibido 2Z alguna vez, la cuenta de tokens existe y puedes omitir este paso. + +--- + +## Paso 5: Verificar + +Comprueba lo que ahora está registrado onchain: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +Ejemplo de salida: + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +La columna `ata` es la cuenta de tokens 2Z en la que se pagará a cada destinatario. Verifica que la columna `proportion` sume 100%. + +--- + +## Cuándo Llegan las Recompensas + +- Las recompensas se calculan por **época DZ**, que es la época del DoubleZero Ledger. Una época DZ dura aproximadamente dos días. +- El pago de una época ocurre alrededor de 10 épocas DZ después de que esa época termina, es decir, aproximadamente 20 días después. Este retraso cubre la contabilidad de la época. +- Los pagos son automáticos. No necesitas reclamarlos y no necesitas ejecutar nada. +- Una vez que tus destinatarios están configurados, los pagos comienzan a llegar en un par de días a medida que se procesan las siguientes épocas. Las épocas que pasaron antes de que configuraras tus destinatarios son un asunto separado, consulta [Si Configuras Esto Tarde](#si-configuras-esto-tarde). +- Una época DZ y una época de Solana no tienen la misma duración. Esa diferencia se acumula con el tiempo, por lo que de vez en cuando una época DZ muestra cero recompensas. Esto es esperado. + +--- + +## Dónde Ver Tus Recompensas + +**Vista agregada.** El [Economic Hub](https://doublezero.xyz/economic-hub) muestra las recompensas de los contribuidores a nivel de red. + +**Por época.** Consulta al protocolo lo que pagó una época DZ determinada: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +La salida lista cada contribuidor con su participación, su recompensa en 2Z, y si el pago ha sido realizado. Busca tu código de contribuidor en la columna `contributor`. + +Para ver en qué época DZ está la red ahora, omite `-e`: + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "Las épocas recientes aún no son definitivas" + Consultar una época cuyas recompensas aún no se han calculado devuelve `Rewards calculation is not finalized yet`. Prueba con una época más antigua. + +--- + +## Si Configuras Esto Tarde + +Las recompensas se calculan para cada época en la que contribuiste, tengas o no destinatarios configurados en ese momento. Esas recompensas no se queman y no expiran. Permanecen en la cuenta de distribución de esa época hasta que alguien envíe el pago. + +El inconveniente es que nada las envía por ti después del hecho. El proceso de pago rutinario trabaja con las épocas recientes, por lo que una época que pasó mientras tu lista de destinatarios estaba vacía permanece sin pagar hasta que se envíe manualmente. + +Para encontrar qué épocas están afectadas, busca filas con tu código de contribuidor donde `distributed` sea `no` y la recompensa sea mayor que cero: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +Enviar el pago es sin permisos (permissionless), así que una vez que tus destinatarios estén configurados, cualquier billetera con fondos puede hacerlo, incluyendo la tuya: + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +Agrega `--dry-run` primero para simularlo sin enviar nada. El comando procesa cada contribuidor en esa época y omite los que ya fueron pagados, así que es seguro ejecutarlo. + +Si prefieres no hacer esto tú mismo, pide a DZF que envíe las épocas por ti. + +--- + +## Cambiar Destinatarios Después + +Repite el [Paso 3](#paso-3-configura-tus-billeteras-destinatarias) en cualquier momento. La nueva lista reemplaza la anterior por completo, así que incluye todos los destinatarios que aún deseas, no solo los que estás agregando. Los porcentajes deben sumar 100 nuevamente. + +Recuerda el [Paso 4](#paso-4-verifica-que-cada-destinatario-pueda-recibir-2z) para cualquier billetera que agregues. + +--- + +## Bloquear la Clave del Gestor de Recompensas + +Por defecto, DZF puede cambiar tu clave del gestor de recompensas, lo cual es útil si pierdes acceso a ella. Si prefieres descartar esa posibilidad, puedes bloquearla: + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "No bloquees una clave que podrías perder" + Una vez que la gestión está bloqueada, nadie puede reemplazar tu clave del gestor de recompensas, incluyendo DZF. Si luego pierdes esa clave, ya no podrás cambiar a dónde van tus recompensas. Solo bloquéala si la clave está respaldada y segura. + +Para permitirlo nuevamente, ejecuta el mismo comando con `--allow-protocol-management`. + +--- + +## Solución de Problemas + +**La columna `manager` está vacía.** +DZF aún no ha registrado tu clave del gestor de recompensas. Envíales la clave pública y pídeles que confirmen. + +**`Invalid rewards manager`.** +El par de claves con el que firmaste no es el gestor de recompensas registrado. Verifica que pasaste el archivo correcto a `-k`, o la billetera correcta en el portal. + +**`Invalid recipients`.** +Tus porcentajes no suman exactamente 100, listaste más de 8 destinatarios, o uno de ellos tiene una participación del 0%. + +**Las recompensas aparecen como ganadas pero nada llega.** +Dos causas comunes. O no hay destinatarios configurados, por lo que no hay a dónde enviarlas, o una billetera destinataria no tiene cuenta de tokens 2Z. Revisa el [Paso 4](#paso-4-verifica-que-cada-destinatario-pueda-recibir-2z) y el [Paso 5](#paso-5-verificar). Una vez corregido, las épocas futuras se pagan solas. Las épocas que ya pasaron necesitan [un pago manual](#si-configuras-esto-tarde). + +**Tus recompensas para una época reciente son 0.** +Las recompensas tienen un retraso de aproximadamente 10 épocas DZ. Consulta una época que tenga al menos esa antigüedad. Las épocas con cero ocasionales también son normales, consulta [Cuándo Llegan las Recompensas](#cuándo-llegan-las-recompensas). + +--- + +## Próximos Pasos + +Vuelve a la [Lista de Verificación de Incorporación](contribute-overview.md#onboarding-checklist), o continúa con [Operaciones](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.fr.md b/docs/contribute-rewards.fr.md new file mode 100644 index 0000000..8809331 --- /dev/null +++ b/docs/contribute-rewards.fr.md @@ -0,0 +1,292 @@ +--- +description: Configurez la gestion des récompenses afin que les récompenses en 2Z générées par votre contribution à DoubleZero soient versées aux portefeuilles que vous contrôlez. +--- + +# Gestion des récompenses + +Vous gagnez des récompenses en [2Z](glossary.md#2z-token) pour la bande passante et les appareils que vous contribuez. Le protocole verse ces récompenses de lui-même, directement aux portefeuilles que vous désignez. Tant que vous ne les avez pas désignés, aucun versement ne peut être effectué. + +!!! warning "Faites ceci lors de la configuration du compte" + Configurez la gestion des récompenses lors de la [Phase 2 : Configuration du compte](contribute-provisioning.md#phase-2-account-setup), avant que votre appareil ne transporte du trafic. + + Vos récompenses continuent de s'accumuler si vous reportez cette étape. Le protocole ne les détruit pas et elles n'expirent pas. Ce que vous perdez, c'est le versement automatique : le processus de versement de routine traite les époques récentes, donc toute époque passée alors que vous n'avez pas de destinataires configurés devra être versée manuellement par la suite. Voir [Si vous configurez ceci tardivement](#si-vous-configurez-ceci-tardivement). + +--- + +## Comment ça fonctionne + +Trois clés sont impliquées. Chacune remplit un rôle différent, et il est plus sûr de les garder séparées. + +| Clé | Ce qu'elle fait | Reçoit des récompenses ? | +|-----|-----------------|--------------------------| +| **Clé de service** | Vous identifie en tant que contributeur et signe vos commandes CLI. Désigne également votre compte de récompenses onchain. | Non | +| **Clé du gestionnaire de récompenses** | Signe les modifications de la liste des portefeuilles recevant les récompenses. | Non | +| **Portefeuille(s) destinataire(s)** | Détient les 2Z que le protocole vous envoie. Jusqu'à 8 portefeuilles. | Oui | + +La DoubleZero Foundation enregistre votre clé de gestionnaire de récompenses en lien avec votre clé de service. Seule la DZF peut le faire. Ensuite, seule votre clé de gestionnaire de récompenses peut modifier la liste des destinataires, et la DZF ne peut pas rediriger vos récompenses. + +```mermaid +flowchart LR + DZF["DZF"] -->|"Enregistre votre
clé de gestionnaire de récompenses"| ACC["Votre compte de récompenses
onchain"] + RM["Clé du gestionnaire de récompenses
(vous la détenez, gardez-la hors ligne)"] -->|"Définit les destinataires
et les pourcentages"| ACC + ACC --> R1["Portefeuille destinataire 1"] + ACC --> R2["Portefeuille destinataire 2"] + PROTO["Le protocole verse
à chaque époque DZ"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## Ce dont vous avez besoin au préalable + +- Un compte contributeur onchain. Vérifiez avec `doublezero contributor list`. +- Un portefeuille Solana pour servir de gestionnaire de récompenses, détenant environ 0,01 SOL pour payer les frais de transaction. +- Un ou plusieurs portefeuilles pour recevoir les 2Z. +- Le CLI `doublezero-solana`, si vous souhaitez utiliser la ligne de commande plutôt que le portail. Installez-le avec `sudo apt update && sudo apt install doublezero-solana`. + +!!! tip "Utilisez un portefeuille matériel pour la clé du gestionnaire de récompenses" + La clé du gestionnaire de récompenses contrôle où va votre argent. Conservez-la sur un portefeuille matériel ou hors ligne. Elle n'a jamais besoin de se trouver sur un serveur, et elle ne détient jamais vos récompenses. + +--- + +## Étape 1 : Créez votre portefeuille de gestionnaire de récompenses + +Créez un portefeuille Solana que vous contrôlez et avec lequel vous pouvez signer. Il peut s'agir d'un portefeuille matériel, d'un portefeuille de navigateur ou d'un fichier de paire de clés. + +Approvisionnez-le avec une petite quantité de SOL, environ 0,01 SOL. Cela sert uniquement à payer les frais réseau lorsque vous modifiez votre liste de destinataires. + +Ne réutilisez pas votre clé de service pour cela. Si la clé de service se trouve sur un serveur de gestion, toute personne ayant accès à ce serveur pourrait rediriger vos récompenses. + +--- + +## Étape 2 : Envoyez la clé publique à la DZF + +Transmettez à la DZF la **clé publique** de votre portefeuille de gestionnaire de récompenses. Ne partagez jamais la clé privée. + +La DZF l'enregistre en lien avec votre clé de service onchain et confirme lorsque c'est fait. Vous ne pouvez pas effectuer cette étape vous-même. + +!!! tip "Envoyez-la en même temps que votre clé de service" + Si vous suivez le [Guide de provisionnement des appareils](contribute-provisioning.md), envoyez cette clé publique en même temps que votre clé de service et votre nom d'utilisateur GitHub, à l'[Étape 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). La DZF enregistre les deux clés dans des transactions séparées, donc les envoyer ensemble permet d'économiser un aller-retour. + +Vous pouvez vérifier qu'elle a bien été enregistrée : + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +La colonne `manager` affiche votre clé de gestionnaire de récompenses. Si elle est vide, la DZF ne l'a pas encore enregistrée. + +--- + +## Étape 3 : Définissez vos portefeuilles destinataires + +Indiquez maintenant où les récompenses doivent être envoyées. Vous pouvez utiliser le portail web ou le CLI. Les deux écrivent la même chose onchain. + +Règles applicables dans les deux cas : + +- Au maximum 8 portefeuilles destinataires. +- Les pourcentages doivent être des nombres entiers et doivent totaliser exactement 100. +- Un destinataire ne peut pas avoir une part de 0 %. Supprimez-le à la place. + +!!! info "Si votre accord avec la DZF inclut un partage de revenus" + Certains contributeurs ont un accord qui partage les récompenses avec la fondation, par exemple lorsque la DZF a fourni le matériel. Si c'est votre cas, la DZF vous fournit l'adresse et le pourcentage à saisir ici. Demandez à la DZF si vous n'êtes pas sûr. + +=== "Portail web" + + 1. Rendez-vous sur [doublezero.xyz/rewards](https://doublezero.xyz/rewards). L'ancienne adresse, `rewards.doublezero.xyz`, redirige ici. + 2. Connectez votre portefeuille de gestionnaire de récompenses avec le bouton de portefeuille en haut à droite. + 3. Sélectionnez votre clé de service dans la liste sur la page suivante. + 4. Saisissez chaque adresse de portefeuille destinataire et son pourcentage. Le total doit être de 100 %. + 5. Cliquez sur **Submit** et approuvez la transaction dans votre portefeuille. + +=== "CLI" + + Exécutez ceci avec votre paire de clés du gestionnaire de récompenses en tant que `-k`. Répétez `--recipient` pour chaque portefeuille. + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | Drapeau | Description | + |---------|-------------| + | `--service-key` | Votre clé de service contributeur. Elle désigne le compte de récompenses onchain. | + | `--recipient` | Un destinataire sous la forme `PUBKEY:PERCENT`. Nombres entiers, de 1 à 100, totalisant 100. Maximum 8. | + | `-k` | Votre paire de clés du gestionnaire de récompenses. La transaction échoue si ce n'est pas le gestionnaire de récompenses enregistré. | + | `-u` | `mainnet-beta`. | + + Ajoutez d'abord `--dry-run` si vous souhaitez simuler la transaction sans l'envoyer. + +--- + +## Étape 4 : Vérifiez que chaque destinataire peut détenir des 2Z + +Le protocole envoie des 2Z par un simple transfert de jetons. Il ne crée **pas** le compte de jetons pour vous. Si un portefeuille destinataire n'a pas de compte de jetons 2Z, le versement pour cette époque échoue. + +L'adresse de mint du 2Z sur mainnet est : + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +Listez les comptes de jetons qu'un portefeuille possède déjà : + +```bash +spl-token accounts --owner -u m +``` + +Si `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` est absent de cette liste, créez le compte une seule fois : + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +N'importe quel portefeuille approvisionné peut payer cela. Cela coûte une petite quantité de SOL et ne doit être fait qu'une seule fois par portefeuille destinataire. + +!!! note "Les portefeuilles qui détiennent déjà des 2Z sont OK" + Si le portefeuille a déjà reçu des 2Z, le compte de jetons existe et vous pouvez ignorer cette étape. + +--- + +## Étape 5 : Vérification + +Vérifiez ce qui est désormais enregistré onchain : + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +Exemple de sortie : + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +La colonne `ata` est le compte de jetons 2Z dans lequel chaque destinataire sera payé. Vérifiez que la colonne `proportion` totalise 100 %. + +--- + +## Quand les récompenses arrivent + +- Les récompenses sont calculées par **époque DZ**, qui est l'époque du DoubleZero Ledger. Une époque DZ dure environ deux jours. +- Le versement pour une époque a lieu environ 10 époques DZ après la fin de cette époque, soit environ 20 jours plus tard. Ce délai couvre la comptabilisation de l'époque. +- Les versements sont automatiques. Vous n'avez pas à les réclamer, et vous n'avez rien à exécuter. +- Une fois vos destinataires définis, les versements commencent à arriver sous quelques jours à mesure que les prochaines époques sont traitées. Les époques passées avant que vous ne définissiez vos destinataires sont un cas à part, voir [Si vous configurez ceci tardivement](#si-vous-configurez-ceci-tardivement). +- Une époque DZ et une époque Solana n'ont pas la même durée. Cette différence s'accumule au fil du temps, si bien que de temps en temps une époque DZ affiche zéro récompense. C'est normal. + +--- + +## Où consulter vos récompenses + +**Vue agrégée.** Le [Economic Hub](https://doublezero.xyz/economic-hub) affiche les récompenses des contributeurs au niveau du réseau. + +**Par époque.** Interrogez le protocole sur ce qu'une époque DZ donnée a versé : + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +La sortie liste chaque contributeur avec sa part, sa récompense en 2Z, et si le versement a été effectué. Retrouvez votre code contributeur dans la colonne `contributor`. + +Pour voir à quelle époque DZ le réseau en est actuellement, omettez `-e` : + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "Les époques récentes ne sont pas encore finalisées" + Interroger une époque dont les récompenses n'ont pas encore été calculées renvoie `Rewards calculation is not finalized yet`. Essayez une époque plus ancienne. + +--- + +## Si vous configurez ceci tardivement + +Les récompenses sont calculées pour chaque époque à laquelle vous avez contribué, que vous ayez eu ou non des destinataires configurés à ce moment-là. Ces récompenses ne sont pas détruites et n'expirent pas. Elles restent dans le compte de distribution de cette époque jusqu'à ce que quelqu'un soumette le versement. + +Le problème est que rien ne les soumet pour vous après coup. Le processus de versement de routine traite les époques récentes, donc une époque passée alors que votre liste de destinataires était vide reste impayée jusqu'à ce qu'elle soit soumise manuellement. + +Pour trouver quelles époques sont concernées, cherchez les lignes avec votre code contributeur où `distributed` est `no` et la récompense est supérieure à zéro : + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +Soumettre le versement est sans permission, donc une fois vos destinataires configurés, n'importe quel portefeuille approvisionné peut le faire, y compris le vôtre : + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +Ajoutez d'abord `--dry-run` pour simuler sans rien envoyer. La commande traite chaque contributeur de cette époque et ignore ceux déjà payés, donc elle est sûre à exécuter. + +Si vous préférez ne pas le faire vous-même, demandez à la DZF de soumettre les époques pour vous. + +--- + +## Modifier les destinataires ultérieurement + +Répétez l'[Étape 3](#etape-3-definissez-vos-portefeuilles-destinataires) à tout moment. La nouvelle liste remplace entièrement l'ancienne, donc incluez chaque destinataire que vous souhaitez toujours, pas seulement ceux que vous ajoutez. Les pourcentages doivent à nouveau totaliser 100. + +N'oubliez pas l'[Étape 4](#etape-4-verifiez-que-chaque-destinataire-peut-detenir-des-2z) pour tout portefeuille que vous ajoutez. + +--- + +## Verrouiller la clé du gestionnaire de récompenses + +Par défaut, la DZF peut modifier votre clé de gestionnaire de récompenses, ce qui est utile si vous en perdez l'accès. Si vous préférez exclure cette possibilité, vous pouvez la bloquer : + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "Ne verrouillez pas une clé que vous pourriez perdre" + Une fois la gestion bloquée, personne ne peut remplacer votre clé de gestionnaire de récompenses, y compris la DZF. Si vous perdez ensuite cette clé, vous ne pourrez plus modifier la destination de vos récompenses. Ne bloquez que si la clé est sauvegardée et en sécurité. + +Pour autoriser à nouveau la gestion, exécutez la même commande avec `--allow-protocol-management`. + +--- + +## Dépannage + +**La colonne `manager` est vide.** +La DZF n'a pas encore enregistré votre clé de gestionnaire de récompenses. Envoyez-leur la clé publique et demandez-leur de confirmer. + +**`Invalid rewards manager`.** +La paire de clés avec laquelle vous avez signé n'est pas le gestionnaire de récompenses enregistré. Vérifiez que vous avez passé le bon fichier à `-k`, ou le bon portefeuille dans le portail. + +**`Invalid recipients`.** +Vos pourcentages ne totalisent pas exactement 100, vous avez listé plus de 8 destinataires, ou l'un d'eux a une part de 0 %. + +**Les récompenses apparaissent comme gagnées mais rien n'arrive.** +Deux causes fréquentes. Soit aucun destinataire n'est configuré, donc il n'y a nulle part où les envoyer, soit un portefeuille destinataire n'a pas de compte de jetons 2Z. Suivez l'[Étape 4](#etape-4-verifiez-que-chaque-destinataire-peut-detenir-des-2z) et l'[Étape 5](#etape-5-verification). Une fois cela corrigé, les époques futures seront versées automatiquement. Les époques déjà passées nécessitent [un versement manuel](#si-vous-configurez-ceci-tardivement). + +**Vos récompenses pour une époque récente sont de 0.** +Les récompenses ont un décalage d'environ 10 époques DZ. Vérifiez une époque qui a au moins cet âge. Des époques occasionnelles à zéro sont également normales, voir [Quand les récompenses arrivent](#quand-les-recompenses-arrivent). + +--- + +## Prochaines étapes + +Retour à la [Liste de contrôle d'intégration](contribute-overview.md#onboarding-checklist), ou passez à [Opérations](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.it.md b/docs/contribute-rewards.it.md new file mode 100644 index 0000000..f48ad03 --- /dev/null +++ b/docs/contribute-rewards.it.md @@ -0,0 +1,292 @@ +--- +description: Configura la gestione delle ricompense affinché le ricompense in 2Z guadagnate con il tuo contributo a DoubleZero vengano pagate ai wallet che controlli. +--- + +# Gestione delle Ricompense + +Guadagni ricompense in [2Z](glossary.md#2z-token) per la larghezza di banda e i dispositivi che contribuisci. Il protocollo paga queste ricompense autonomamente, direttamente ai wallet che designi. Finché non li designi, nessun pagamento può essere effettuato. + +!!! warning "Fai questo durante la configurazione dell'account" + Configura la gestione delle ricompense nella [Fase 2: Configurazione dell'Account](contribute-provisioning.md#phase-2-account-setup), prima che il tuo dispositivo trasporti traffico. + + Le tue ricompense continuano a maturare anche se rimandi questa operazione. Il protocollo non le brucia e non scadono. Ciò che perdi è il pagamento automatico: il processo di pagamento di routine elabora le epoche recenti, quindi qualsiasi epoca trascorsa mentre non hai destinatari configurati dovrà essere pagata manualmente in seguito. Vedi [Se Configuri Questo in Ritardo](#se-configuri-questo-in-ritardo). + +--- + +## Come Funziona + +Sono coinvolte tre chiavi. Ognuna svolge un compito diverso, ed è più sicuro tenerle separate. + +| Chiave | Cosa fa | Riceve ricompense? | +|--------|---------|-------------------| +| **Chiave di servizio** | Ti identifica come contributore e firma i tuoi comandi CLI. Inoltre nomina il tuo account ricompense onchain. | No | +| **Chiave del gestore ricompense** | Firma le modifiche alla lista dei wallet che ricevono le ricompense. | No | +| **Wallet destinatari** | Contiene i 2Z che il protocollo ti invia. Fino a 8 wallet. | Sì | + +La DoubleZero Foundation registra la tua chiave del gestore ricompense associandola alla tua chiave di servizio. Solo DZF può farlo. Dopodiché, solo la tua chiave del gestore ricompense può modificare la lista dei destinatari, e DZF non può reindirizzare le tue ricompense. + +```mermaid +flowchart LR + DZF["DZF"] -->|"Registra la tua
chiave del gestore ricompense"| ACC["Il tuo account ricompense
onchain"] + RM["Chiave del gestore ricompense
(la tieni tu, conservala offline)"] -->|"Imposta destinatari
e percentuali"| ACC + ACC --> R1["Wallet destinatario 1"] + ACC --> R2["Wallet destinatario 2"] + PROTO["Il protocollo paga
ogni epoca DZ"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## Cosa Ti Serve Prima + +- Un account contributore onchain. Verifica con `doublezero contributor list`. +- Un wallet Solana da usare come gestore ricompense, con circa 0,01 SOL per pagare le commissioni di transazione. +- Uno o più wallet per ricevere i 2Z. +- La CLI `doublezero-solana`, se vuoi usare la riga di comando invece del portale. Installala con `sudo apt update && sudo apt install doublezero-solana`. + +!!! tip "Usa un hardware wallet per la chiave del gestore ricompense" + La chiave del gestore ricompense controlla dove vanno i tuoi fondi. Conservala su un hardware wallet o comunque offline. Non ha mai bisogno di risiedere su un server e non detiene mai le tue ricompense. + +--- + +## Passo 1: Crea il Tuo Wallet del Gestore Ricompense + +Crea un wallet Solana che controlli e con cui puoi firmare. Può essere un hardware wallet, un wallet del browser o un file keypair. + +Caricalo con una piccola quantità di SOL, circa 0,01 SOL. Questo serve solo a pagare le commissioni di rete quando modifichi la lista dei destinatari. + +Non riutilizzare la tua chiave di servizio per questo. Se la chiave di servizio risiede su un server di gestione, chiunque raggiunga quel server potrebbe reindirizzare le tue ricompense. + +--- + +## Passo 2: Invia la Chiave Pubblica a DZF + +Fornisci a DZF la **chiave pubblica** del tuo wallet del gestore ricompense. Non condividere mai la chiave privata. + +DZF la registra associandola alla tua chiave di servizio onchain e conferma quando è completato. Non puoi eseguire questo passaggio autonomamente. + +!!! tip "Inviala insieme alla tua chiave di servizio" + Se stai seguendo la [Guida al Provisioning del Dispositivo](contribute-provisioning.md), invia questa chiave pubblica contemporaneamente alla tua chiave di servizio e al nome utente GitHub, nel [Passo 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). DZF registra le due chiavi in transazioni separate, quindi inviarle insieme fa risparmiare un passaggio. + +Puoi verificare che sia stata registrata: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +La colonna `manager` mostra la tua chiave del gestore ricompense. Se è vuota, DZF non l'ha ancora registrata. + +--- + +## Passo 3: Imposta i Tuoi Wallet Destinatari + +Ora indica dove devono andare le ricompense. Puoi usare il portale web o la CLI. Entrambi scrivono la stessa cosa onchain. + +Regole valide in entrambi i casi: + +- Al massimo 8 wallet destinatari. +- Le percentuali devono essere numeri interi e devono sommare esattamente a 100. +- Un destinatario non può avere una quota dello 0%. Rimuovilo invece. + +!!! info "Se il tuo accordo con DZF include una condivisione dei ricavi" + Alcuni contributori hanno un accordo che divide le ricompense con la fondazione, ad esempio quando DZF ha fornito l'hardware. Se questo si applica a te, DZF ti fornisce l'indirizzo e la percentuale da inserire qui. Chiedi a DZF se non sei sicuro. + +=== "Portale web" + + 1. Vai su [doublezero.xyz/rewards](https://doublezero.xyz/rewards). Il vecchio indirizzo, `rewards.doublezero.xyz`, reindirizza qui. + 2. Collega il tuo wallet del gestore ricompense con il pulsante wallet in alto a destra. + 3. Seleziona la tua chiave di servizio dalla lista nella pagina successiva. + 4. Inserisci l'indirizzo di ogni wallet destinatario e la sua percentuale. Il totale deve essere 100%. + 5. Clicca **Submit** e approva la transazione nel tuo wallet. + +=== "CLI" + + Esegui questo comando con il keypair del tuo gestore ricompense come `-k`. Ripeti `--recipient` per ogni wallet. + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | Flag | Descrizione | + |------|-------------| + | `--service-key` | La tua chiave di servizio come contributore. Questa nomina l'account ricompense onchain. | + | `--recipient` | Un destinatario nel formato `PUBKEY:PERCENT`. Numeri interi, da 1 a 100, che sommano a 100. Massimo 8. | + | `-k` | Il keypair del tuo gestore ricompense. La transazione fallisce se questo non è il gestore ricompense registrato. | + | `-u` | `mainnet-beta`. | + + Aggiungi `--dry-run` prima se vuoi simulare la transazione senza inviarla. + +--- + +## Passo 4: Verifica che Ogni Destinatario Possa Detenere 2Z + +Il protocollo invia 2Z con un semplice trasferimento di token. **Non** crea l'account token per te. Se un wallet destinatario non ha un account token 2Z, il pagamento per quell'epoca fallisce. + +Il mint 2Z su mainnet è: + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +Elenca gli account token che un wallet già possiede: + +```bash +spl-token accounts --owner -u m +``` + +Se `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` manca da quella lista, crea l'account una volta: + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +Qualsiasi wallet con fondi può pagare per questo. Costa una piccola quantità di SOL e deve essere fatto solo una volta per wallet destinatario. + +!!! note "I wallet che già detengono 2Z vanno bene" + Se il wallet ha già ricevuto 2Z in precedenza, l'account token esiste e puoi saltare questo passaggio. + +--- + +## Passo 5: Verifica + +Controlla cosa è ora registrato onchain: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +Output di esempio: + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +La colonna `ata` è l'account token 2Z in cui ogni destinatario riceverà il pagamento. Verifica che la colonna `proportion` sommi al 100%. + +--- + +## Quando Arrivano le Ricompense + +- Le ricompense vengono calcolate per **epoca DZ**, che è l'epoca del DoubleZero Ledger. Un'epoca DZ dura circa due giorni. +- Il pagamento per un'epoca avviene circa 10 epoche DZ dopo la fine di quell'epoca, quindi circa 20 giorni dopo. Questo ritardo copre la contabilità dell'epoca. +- I pagamenti sono automatici. Non devi reclamarli e non devi eseguire nulla. +- Una volta configurati i destinatari, i pagamenti iniziano ad arrivare entro un paio di giorni man mano che le epoche successive vengono elaborate. Le epoche trascorse prima della configurazione dei destinatari sono una questione separata, vedi [Se Configuri Questo in Ritardo](#se-configuri-questo-in-ritardo). +- Un'epoca DZ e un'epoca Solana non hanno la stessa durata. Questa differenza si accumula nel tempo, quindi di tanto in tanto un'epoca DZ mostra zero ricompense. Questo è normale. + +--- + +## Dove Vedere le Tue Ricompense + +**Vista aggregata.** L'[Economic Hub](https://doublezero.xyz/economic-hub) mostra le ricompense dei contributori a livello di rete. + +**Per epoca.** Chiedi al protocollo cosa ha pagato una determinata epoca DZ: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +L'output elenca ogni contributore con la sua quota, la sua ricompensa in 2Z e se il pagamento è stato effettuato. Cerca il tuo codice contributore nella colonna `contributor`. + +Per vedere in quale epoca DZ si trova attualmente la rete, ometti `-e`: + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "Le epoche recenti non sono ancora finalizzate" + Richiedere un'epoca le cui ricompense non sono ancora state calcolate restituisce `Rewards calculation is not finalized yet`. Prova con un'epoca più vecchia. + +--- + +## Se Configuri Questo in Ritardo + +Le ricompense vengono calcolate per ogni epoca in cui hai contribuito, indipendentemente dal fatto che avessi o meno dei destinatari configurati in quel momento. Queste ricompense non vengono bruciate e non scadono. Restano nell'account di distribuzione di quell'epoca finché qualcuno non invia il pagamento. + +Il problema è che nessuno le invia per te a posteriori. Il processo di pagamento di routine elabora le epoche recenti, quindi un'epoca trascorsa mentre la tua lista destinatari era vuota resta non pagata finché non viene inviata manualmente. + +Per trovare quali epoche sono interessate, cerca le righe con il tuo codice contributore dove `distributed` è `no` e la ricompensa è superiore a zero: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +L'invio del pagamento è permissionless, quindi una volta configurati i destinatari, qualsiasi wallet con fondi può farlo, incluso il tuo: + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +Aggiungi `--dry-run` prima per simulare senza inviare nulla. Il comando elabora ogni contributore in quell'epoca e salta quelli già pagati, quindi è sicuro da eseguire. + +Se preferisci non farlo tu stesso, chiedi a DZF di inviare le epoche per te. + +--- + +## Modificare i Destinatari Successivamente + +Ripeti il [Passo 3](#passo-3-imposta-i-tuoi-wallet-destinatari) in qualsiasi momento. La nuova lista sostituisce completamente quella vecchia, quindi includi ogni destinatario che desideri ancora, non solo quelli che stai aggiungendo. Le percentuali devono sommare di nuovo a 100. + +Ricordati del [Passo 4](#passo-4-verifica-che-ogni-destinatario-possa-detenere-2z) per ogni wallet che aggiungi. + +--- + +## Bloccare la Chiave del Gestore Ricompense + +Per impostazione predefinita DZF può cambiare la tua chiave del gestore ricompense, il che è utile se perdi l'accesso ad essa. Se preferisci escludere questa possibilità, puoi bloccarla: + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "Non bloccare una chiave che potresti perdere" + Una volta bloccata la gestione, nessuno può sostituire la tua chiave del gestore ricompense, inclusa DZF. Se poi perdi quella chiave non potrai più cambiare dove vanno le tue ricompense. Blocca solo se la chiave è salvata in backup e al sicuro. + +Per consentirla di nuovo, esegui lo stesso comando con `--allow-protocol-management`. + +--- + +## Risoluzione dei Problemi + +**La colonna `manager` è vuota.** +DZF non ha ancora registrato la tua chiave del gestore ricompense. Invia loro la chiave pubblica e chiedi conferma. + +**`Invalid rewards manager`.** +Il keypair con cui hai firmato non è il gestore ricompense registrato. Verifica di aver passato il file corretto a `-k`, o il wallet corretto nel portale. + +**`Invalid recipients`.** +Le tue percentuali non sommano esattamente a 100, hai elencato più di 8 destinatari, oppure uno di essi ha una quota dello 0%. + +**Le ricompense risultano guadagnate ma non arriva nulla.** +Due cause comuni. O non sono configurati destinatari, quindi non c'è dove inviarle, oppure un wallet destinatario non ha un account token 2Z. Segui il [Passo 4](#passo-4-verifica-che-ogni-destinatario-possa-detenere-2z) e il [Passo 5](#passo-5-verifica). Una volta risolto, le epoche future vengono pagate automaticamente. Le epoche già trascorse necessitano di [un pagamento manuale](#se-configuri-questo-in-ritardo). + +**Le tue ricompense per un'epoca recente sono 0.** +Le ricompense hanno un ritardo di circa 10 epoche DZ. Controlla un'epoca che sia almeno così vecchia. Epoche occasionali con zero sono anche normali, vedi [Quando Arrivano le Ricompense](#quando-arrivano-le-ricompense). + +--- + +## Prossimi Passi + +Torna alla [Checklist di Onboarding](contribute-overview.md#onboarding-checklist), oppure prosegui con [Operazioni](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.ja.md b/docs/contribute-rewards.ja.md new file mode 100644 index 0000000..02ccb17 --- /dev/null +++ b/docs/contribute-rewards.ja.md @@ -0,0 +1,292 @@ +--- +description: DoubleZero への貢献で獲得した 2Z 報酬が、あなたが管理するウォレットに支払われるようにリワード管理を設定します。 +--- + +# リワード管理 + +あなたが提供する帯域幅やデバイスに対して、[2Z](glossary.md#2z-token) で報酬を獲得できます。プロトコルはこれらの報酬を、あなたが指定したウォレットに直接自動的に支払います。ウォレットを指定するまで、報酬は支払われません。 + +!!! warning "アカウントセットアップ時に行ってください" + リワード管理は、デバイスがトラフィックを処理する前に [フェーズ 2: アカウントセットアップ](contribute-provisioning.md#phase-2-account-setup) で設定してください。 + + この設定を後回しにしても報酬は引き続き蓄積されます。プロトコルは報酬をバーンせず、有効期限もありません。失われるのは自動支払いです。定期的な支払いプロセスは直近のエポックを処理するため、受取人が設定されていない間に過ぎたエポックの報酬は、後から手動で支払う必要があります。[設定が遅れた場合](#if-you-set-this-up-late)を参照してください。 + +--- + +## 仕組み + +3 つの鍵が関係しています。それぞれ異なる役割を持ち、分離して管理する方が安全です。 + +| 鍵 | 役割 | 報酬を受け取る？ | +|-----|--------------|-------------------| +| **サービスキー** | コントリビューターとしてあなたを識別し、CLI コマンドに署名します。また、オンチェーンの報酬アカウントの名前にもなります。 | いいえ | +| **リワードマネージャーキー** | 報酬を受け取るウォレットリストの変更に署名します。 | いいえ | +| **受取ウォレット** | プロトコルから送られる 2Z を保持します。最大 8 ウォレット。 | はい | + +DoubleZero Foundation（DZF）がサービスキーに対してリワードマネージャーキーを登録します。この操作は DZF のみが行えます。登録後は、受取人リストを変更できるのはリワードマネージャーキーだけとなり、DZF があなたの報酬をリダイレクトすることはできません。 + +```mermaid +flowchart LR + DZF["DZF"] -->|"リワードマネージャーキー
を登録"| ACC["あなたの報酬アカウント
（オンチェーン）"] + RM["リワードマネージャーキー
（あなたが保持、オフラインで保管）"] -->|"受取人と
割合を設定"| ACC + ACC --> R1["受取ウォレット 1"] + ACC --> R2["受取ウォレット 2"] + PROTO["プロトコルが各 DZ エポック
ごとに支払い"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## 事前に必要なもの + +- オンチェーンのコントリビューターアカウント。`doublezero contributor list` で確認できます。 +- リワードマネージャーとして使用する Solana ウォレット。トランザクション手数料を支払うために約 0.01 SOL を保持してください。 +- 2Z を受け取るための 1 つ以上のウォレット。 +- ポータルではなくコマンドラインを使用する場合は `doublezero-solana` CLI。`sudo apt update && sudo apt install doublezero-solana` でインストールできます。 + +!!! tip "リワードマネージャーキーにはハードウェアウォレットを使用してください" + リワードマネージャーキーはあなたの資金の送付先を管理します。ハードウェアウォレットまたはその他のオフライン手段で保管してください。サーバー上に置く必要はなく、報酬を保持することもありません。 + +--- + +## ステップ 1: リワードマネージャーウォレットの作成 + +あなたが管理し、署名できる Solana ウォレットを作成します。ハードウェアウォレット、ブラウザウォレット、またはキーペアファイルのいずれでも構いません。 + +少額の SOL（約 0.01 SOL）をチャージしてください。これは受取人リストを変更する際のネットワーク手数料の支払いにのみ使用されます。 + +サービスキーをこの用途で再利用しないでください。サービスキーが管理サーバー上にある場合、そのサーバーにアクセスできる者が報酬の送付先を変更できてしまいます。 + +--- + +## ステップ 2: 公開鍵を DZF に送信 + +リワードマネージャーウォレットの**公開鍵**を DZF に送ります。秘密鍵は絶対に共有しないでください。 + +DZF がオンチェーンであなたのサービスキーに対してそれを登録し、完了を確認します。このステップを自分で行うことはできません。 + +!!! tip "サービスキーと一緒に送信してください" + [デバイスプロビジョニングガイド](contribute-provisioning.md)に沿って作業している場合は、[ステップ 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf) でサービスキーと GitHub ユーザー名と一緒にこの公開鍵を送信してください。DZF は 2 つの鍵を別々のトランザクションで登録するため、同時に送ることでやり取りの往復を節約できます。 + +登録が完了したか確認できます： + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +`manager` 列にリワードマネージャーキーが表示されます。空の場合、DZF がまだ登録していません。 + +--- + +## ステップ 3: 受取ウォレットの設定 + +報酬の送付先を指定します。Web ポータルまたは CLI を使用できます。どちらもオンチェーンに同じ内容を書き込みます。 + +どちらの方法でも適用されるルール： + +- 受取ウォレットは最大 8 つ。 +- 割合は整数で、合計がちょうど 100 になる必要があります。 +- 受取人に 0% のシェアを設定することはできません。代わりに削除してください。 + +!!! info "DZF との契約にレベニューシェアが含まれている場合" + 一部のコントリビューターは、DZF がハードウェアを提供した場合など、報酬をファウンデーションと分配する契約を結んでいます。該当する場合、DZF がここに入力するアドレスと割合を提供します。不明な場合は DZF にお問い合わせください。 + +=== "Web ポータル" + + 1. [doublezero.xyz/rewards](https://doublezero.xyz/rewards) にアクセスします。旧アドレス `rewards.doublezero.xyz` はここにリダイレクトされます。 + 2. 右上のウォレットボタンでリワードマネージャーウォレットを接続します。 + 3. 次のページのリストからサービスキーを選択します。 + 4. 各受取ウォレットのアドレスと割合を入力します。合計は 100% にする必要があります。 + 5. **Submit** をクリックし、ウォレットでトランザクションを承認します。 + +=== "CLI" + + リワードマネージャーのキーペアを `-k` として指定して実行します。ウォレットごとに `--recipient` を繰り返します。 + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | フラグ | 説明 | + |------|-------------| + | `--service-key` | コントリビューターのサービスキー。オンチェーンの報酬アカウントの名前になります。 | + | `--recipient` | `PUBKEY:PERCENT` 形式の受取人。整数、1 から 100、合計 100。最大 8 つ。 | + | `-k` | リワードマネージャーのキーペア。登録されたリワードマネージャーでない場合、トランザクションは失敗します。 | + | `-u` | `mainnet-beta`。 | + + 送信せずにトランザクションをシミュレーションしたい場合は、先に `--dry-run` を追加してください。 + +--- + +## ステップ 4: 各受取人が 2Z を保持できるか確認 + +プロトコルはプレーンなトークン転送で 2Z を送信します。トークンアカウントを自動で作成することは**ありません**。受取ウォレットに 2Z トークンアカウントがない場合、そのエポックの支払いは失敗します。 + +メインネットの 2Z ミントアドレスは： + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +ウォレットが既に持っているトークンアカウントを一覧表示します： + +```bash +spl-token accounts --owner -u m +``` + +`J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` がリストにない場合、一度だけアカウントを作成します： + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +任意の資金が入ったウォレットで支払えます。少額の SOL がかかり、受取ウォレットごとに一度だけ行う必要があります。 + +!!! note "既に 2Z を保持しているウォレットは問題ありません" + そのウォレットが 2Z を受け取ったことがある場合、トークンアカウントは既に存在しているため、このステップはスキップできます。 + +--- + +## ステップ 5: 確認 + +オンチェーンに記録されている内容を確認します： + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +出力例： + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +`ata` 列は各受取人に支払われる 2Z トークンアカウントです。`proportion` 列の合計が 100% になっていることを確認してください。 + +--- + +## 報酬が届くタイミング + +- 報酬は **DZ エポック**（DoubleZero Ledger のエポック）ごとに計算されます。DZ エポックはおよそ 2 日間です。 +- エポックの支払いは、そのエポック終了後約 10 DZ エポック（約 20 日後）に行われます。この遅延はエポックの会計処理をカバーするためです。 +- 支払いは自動的に行われます。請求する必要はなく、何かを実行する必要もありません。 +- 受取人を設定すると、次のエポックが処理されるにつれて数日以内に支払いが届き始めます。受取人を設定する前に過ぎたエポックについては別の問題です。[設定が遅れた場合](#if-you-set-this-up-late)を参照してください。 +- DZ エポックと Solana エポックは長さが異なります。この差は時間とともに蓄積されるため、時折 DZ エポックの報酬がゼロになることがあります。これは正常です。 + +--- + +## 報酬の確認方法 + +**集計ビュー。** [Economic Hub](https://doublezero.xyz/economic-hub) でネットワークレベルのコントリビューター報酬を確認できます。 + +**エポックごと。** 特定の DZ エポックの支払い内容をプロトコルに問い合わせます： + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +出力には、各コントリビューターのシェア、2Z での報酬額、および支払いが行われたかどうかが一覧表示されます。`contributor` 列であなたのコントリビューターコードを見つけてください。 + +現在のネットワークの DZ エポックを確認するには、`-e` を省略します： + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "直近のエポックはまだ確定していません" + 報酬がまだ計算されていないエポックを問い合わせると `Rewards calculation is not finalized yet` と返されます。もっと古いエポックを試してください。 + +--- + +## 設定が遅れた場合 + +報酬は、受取人が設定されていたかどうかに関わらず、あなたが貢献したすべてのエポックについて計算されます。これらの報酬はバーンされず、有効期限もありません。誰かが支払いを送信するまで、そのエポックの分配アカウントに残り続けます。 + +問題は、事後に自動で送信してくれるものがないことです。定期的な支払いプロセスは直近のエポックを処理するため、受取人リストが空の間に過ぎたエポックは、手動で送信されるまで未払いのままです。 + +影響を受けるエポックを見つけるには、あなたのコントリビューターコードで `distributed` が `no` かつ報酬がゼロ以上の行を探します： + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +支払いの送信はパーミッションレスなので、受取人が設定された後は、あなた自身を含む任意の資金が入ったウォレットで実行できます： + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +送信せずにシミュレーションするには、先に `--dry-run` を追加してください。このコマンドはそのエポックのすべてのコントリビューターを処理し、既に支払い済みのものはスキップするため、安全に実行できます。 + +自分で行いたくない場合は、DZF にエポックの送信を依頼してください。 + +--- + +## 受取人の変更 + +いつでも[ステップ 3](#step-3-set-your-recipient-wallets) を繰り返すことができます。新しいリストは古いリストを完全に置き換えるため、追加するものだけでなく、引き続き必要なすべての受取人を含めてください。割合は再び合計 100 にする必要があります。 + +追加するウォレットについては[ステップ 4](#step-4-check-each-recipient-can-hold-2z) を忘れないでください。 + +--- + +## リワードマネージャーキーのロック + +デフォルトでは、DZF はリワードマネージャーキーを変更できます。これはキーへのアクセスを失った場合に便利です。この可能性を排除したい場合は、ブロックできます： + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "失う可能性のあるキーをロックしないでください" + 管理がブロックされると、DZF を含め誰もリワードマネージャーキーを置き換えることができなくなります。そのキーを紛失した場合、報酬の送付先を変更できなくなります。キーがバックアップされ安全に保管されている場合にのみブロックしてください。 + +再び許可するには、同じコマンドを `--allow-protocol-management` で実行します。 + +--- + +## トラブルシューティング + +**`manager` 列が空。** +DZF がまだリワードマネージャーキーを登録していません。公開鍵を送信し、確認を依頼してください。 + +**`Invalid rewards manager`。** +署名に使用したキーペアが登録されたリワードマネージャーではありません。`-k` に正しいファイルを渡したか、ポータルで正しいウォレットを使用しているか確認してください。 + +**`Invalid recipients`。** +割合の合計がちょうど 100 になっていないか、受取人が 8 つを超えているか、いずれかの受取人が 0% のシェアになっています。 + +**報酬は獲得済みと表示されるが届かない。** +一般的な原因が 2 つあります。受取人が設定されていないため送付先がないか、受取ウォレットに 2Z トークンアカウントがないかのいずれかです。[ステップ 4](#step-4-check-each-recipient-can-hold-2z) と[ステップ 5](#step-5-verify) を確認してください。修正後、将来のエポックは自動的に支払われます。既に過ぎたエポックには[手動での支払い](#if-you-set-this-up-late)が必要です。 + +**直近のエポックの報酬が 0。** +報酬には約 10 DZ エポックの遅延があります。少なくともそれだけ古いエポックを確認してください。時折ゼロのエポックが発生するのも正常です。[報酬が届くタイミング](#when-rewards-arrive)を参照してください。 + +--- + +## 次のステップ + +[オンボーディングチェックリスト](contribute-overview.md#onboarding-checklist)に戻るか、[運用](contribute-operations.md)に進んでください。 \ No newline at end of file diff --git a/docs/contribute-rewards.ko.md b/docs/contribute-rewards.ko.md new file mode 100644 index 0000000..174f1dc --- /dev/null +++ b/docs/contribute-rewards.ko.md @@ -0,0 +1,292 @@ +--- +description: DoubleZero 기여로 획득한 2Z 보상이 본인이 관리하는 지갑으로 지급되도록 보상 관리를 설정하세요. +--- + +# 보상 관리 + +기여한 대역폭과 장치에 대해 [2Z](glossary.md#2z-token)로 보상을 받습니다. 프로토콜은 지정한 지갑으로 직접 보상을 자동 지급합니다. 지갑을 지정하기 전까지는 어떤 보상도 지급되지 않습니다. + +!!! warning "계정 설정 시 이 작업을 수행하세요" + [2단계: 계정 설정](contribute-provisioning.md#phase-2-account-setup)에서 장치가 트래픽을 처리하기 전에 보상 관리를 설정하세요. + + 나중에 설정하더라도 보상은 계속 적립됩니다. 프로토콜은 보상을 소각하지 않으며 만료되지도 않습니다. 잃게 되는 것은 자동 지급입니다: 정기 지급 프로세스는 최근 에포크를 순차적으로 처리하므로, 수신자가 설정되지 않은 상태에서 지나간 에포크의 보상은 이후 수동으로 지급해야 합니다. [늦게 설정한 경우](#if-you-set-this-up-late)를 참조하세요. + +--- + +## 작동 방식 + +세 가지 키가 관련됩니다. 각 키는 서로 다른 역할을 하며, 분리하여 보관하는 것이 더 안전합니다. + +| 키 | 역할 | 보상 수신 여부 | +|-----|--------------|-------------------| +| **서비스 키** | 기여자로서의 신원을 확인하고 CLI 명령에 서명합니다. 또한 온체인에서 보상 계정의 이름이 됩니다. | 아니오 | +| **보상 관리자 키** | 보상을 수신하는 지갑 목록의 변경 사항에 서명합니다. | 아니오 | +| **수신 지갑** | 프로토콜이 보내는 2Z를 보관합니다. 최대 8개 지갑. | 예 | + +DoubleZero Foundation(DZF)이 서비스 키에 보상 관리자 키를 등록합니다. DZF만 이 작업을 수행할 수 있습니다. 등록 이후에는 보상 관리자 키만 수신자 목록을 변경할 수 있으며, DZF는 보상을 다른 곳으로 돌릴 수 없습니다. + +```mermaid +flowchart LR + DZF["DZF"] -->|"보상 관리자 키를
등록"| ACC["온체인 보상 계정"] + RM["보상 관리자 키
(본인 보관, 오프라인 유지)"] -->|"수신자 및
비율 설정"| ACC + ACC --> R1["수신 지갑 1"] + ACC --> R2["수신 지갑 2"] + PROTO["프로토콜이 매 DZ 에포크마다
지급"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## 사전 준비 사항 + +- 온체인 기여자 계정. `doublezero contributor list`로 확인하세요. +- 보상 관리자로 사용할 Solana 지갑. 트랜잭션 수수료 지불을 위해 약 0.01 SOL이 필요합니다. +- 2Z를 수신할 하나 이상의 지갑. +- 포털 대신 명령줄을 사용하려면 `doublezero-solana` CLI가 필요합니다. `sudo apt update && sudo apt install doublezero-solana`로 설치하세요. + +!!! tip "보상 관리자 키에는 하드웨어 지갑을 사용하세요" + 보상 관리자 키는 보상이 어디로 전송되는지를 제어합니다. 하드웨어 지갑에 보관하거나 오프라인으로 유지하세요. 서버에 놓아둘 필요가 없으며, 보상을 직접 보관하지도 않습니다. + +--- + +## 1단계: 보상 관리자 지갑 생성 + +본인이 관리하고 서명할 수 있는 Solana 지갑을 생성하세요. 하드웨어 지갑, 브라우저 지갑 또는 키페어 파일이 될 수 있습니다. + +약 0.01 SOL 정도의 소량의 SOL을 충전하세요. 이는 수신자 목록을 변경할 때 네트워크 수수료를 지불하는 데만 사용됩니다. + +이 용도로 서비스 키를 재사용하지 마세요. 서비스 키가 관리 서버에 있는 경우, 해당 서버에 접근하는 누구든 보상을 다른 곳으로 돌릴 수 있습니다. + +--- + +## 2단계: 공개 키를 DZF에 전송 + +보상 관리자 지갑의 **공개 키**를 DZF에 전달하세요. 개인 키는 절대 공유하지 마세요. + +DZF가 서비스 키에 대해 온체인으로 등록하고 완료되면 확인해 줍니다. 이 단계는 직접 수행할 수 없습니다. + +!!! tip "서비스 키와 함께 전송하세요" + [장치 프로비저닝 가이드](contribute-provisioning.md)를 따라 진행 중이라면, [2.4단계](contribute-provisioning.md#step-24-submit-keys-to-dzf)에서 서비스 키 및 GitHub 사용자명과 함께 이 공개 키를 전송하세요. DZF는 두 키를 별도의 트랜잭션으로 등록하므로, 함께 보내면 왕복 과정을 줄일 수 있습니다. + +등록 확인 방법: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +`manager` 열에 보상 관리자 키가 표시됩니다. 비어 있다면 DZF가 아직 등록하지 않은 것입니다. + +--- + +## 3단계: 수신 지갑 설정 + +보상이 어디로 전송되어야 하는지 지정합니다. 웹 포털 또는 CLI를 사용할 수 있습니다. 둘 다 동일한 내용을 온체인에 기록합니다. + +두 방법 모두에 적용되는 규칙: + +- 수신 지갑은 최대 8개. +- 비율은 정수여야 하며 합계가 정확히 100이어야 합니다. +- 수신자의 비율을 0%로 설정할 수 없습니다. 대신 제거하세요. + +!!! info "DZF와의 계약에 수익 분배가 포함된 경우" + 일부 기여자는 재단과 보상을 분배하는 계약을 맺고 있습니다. 예를 들어 DZF가 하드웨어를 제공한 경우입니다. 해당되는 경우 DZF가 여기에 입력할 주소와 비율을 알려줍니다. 확실하지 않으면 DZF에 문의하세요. + +=== "웹 포털" + + 1. [doublezero.xyz/rewards](https://doublezero.xyz/rewards)로 이동하세요. 이전 주소인 `rewards.doublezero.xyz`는 여기로 리디렉션됩니다. + 2. 오른쪽 상단의 지갑 버튼으로 보상 관리자 지갑을 연결하세요. + 3. 다음 페이지의 목록에서 서비스 키를 선택하세요. + 4. 각 수신 지갑 주소와 비율을 입력하세요. 합계는 100%여야 합니다. + 5. **Submit**을 클릭하고 지갑에서 트랜잭션을 승인하세요. + +=== "CLI" + + 보상 관리자 키페어를 `-k`로 지정하여 실행하세요. 각 지갑마다 `--recipient`를 반복하세요. + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | 플래그 | 설명 | + |------|-------------| + | `--service-key` | 기여자 서비스 키. 온체인에서 보상 계정의 이름이 됩니다. | + | `--recipient` | `PUBKEY:PERCENT` 형식의 수신자. 정수, 1~100, 합계 100. 최대 8개. | + | `-k` | 보상 관리자 키페어. 등록된 보상 관리자가 아니면 트랜잭션이 실패합니다. | + | `-u` | `mainnet-beta`. | + + 트랜잭션을 전송하지 않고 시뮬레이션하려면 먼저 `--dry-run`을 추가하세요. + +--- + +## 4단계: 각 수신 지갑이 2Z를 보관할 수 있는지 확인 + +프로토콜은 일반 토큰 전송으로 2Z를 보냅니다. 토큰 계정을 대신 생성해 주지 **않습니다**. 수신 지갑에 2Z 토큰 계정이 없으면 해당 에포크의 지급이 실패합니다. + +메인넷의 2Z 민트 주소: + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +지갑이 이미 보유한 토큰 계정 목록 확인: + +```bash +spl-token accounts --owner -u m +``` + +`J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd`가 목록에 없으면 한 번만 계정을 생성하세요: + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +잔액이 있는 아무 지갑이나 이 비용을 지불할 수 있습니다. 소량의 SOL이 필요하며 수신 지갑당 한 번만 수행하면 됩니다. + +!!! note "이미 2Z를 보유한 지갑은 괜찮습니다" + 지갑이 이전에 2Z를 수신한 적이 있다면 토큰 계정이 이미 존재하므로 이 단계를 건너뛸 수 있습니다. + +--- + +## 5단계: 확인 + +온체인에 기록된 내용을 확인하세요: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +출력 예시: + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +`ata` 열은 각 수신자가 보상을 받을 2Z 토큰 계정입니다. `proportion` 열의 합계가 100%인지 확인하세요. + +--- + +## 보상 도착 시점 + +- 보상은 **DZ 에포크**(DoubleZero Ledger의 에포크) 단위로 산정됩니다. DZ 에포크는 약 2일 주기입니다. +- 에포크에 대한 지급은 해당 에포크 종료 후 약 10 DZ 에포크(약 20일 후)에 이루어집니다. 이 지연은 에포크에 대한 정산 기간입니다. +- 지급은 자동입니다. 청구할 필요도, 별도로 실행할 것도 없습니다. +- 수신자가 설정되면 다음 에포크가 처리되면서 며칠 내에 지급이 시작됩니다. 수신자를 설정하기 전에 지나간 에포크는 별도의 문제입니다. [늦게 설정한 경우](#if-you-set-this-up-late)를 참조하세요. +- DZ 에포크와 Solana 에포크는 길이가 같지 않습니다. 이 차이가 시간이 지남에 따라 누적되므로 가끔 DZ 에포크의 보상이 0으로 표시됩니다. 이는 정상입니다. + +--- + +## 보상 확인 방법 + +**종합 뷰.** [Economic Hub](https://doublezero.xyz/economic-hub)에서 네트워크 수준의 기여자 보상을 확인할 수 있습니다. + +**에포크별.** 특정 DZ 에포크의 지급 내역을 프로토콜에 조회합니다: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +출력에는 모든 기여자의 지분, 2Z 보상 금액, 지급 완료 여부가 나열됩니다. `contributor` 열에서 본인의 기여자 코드를 찾으세요. + +현재 네트워크의 DZ 에포크를 확인하려면 `-e`를 생략하세요: + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "최근 에포크는 아직 확정되지 않았습니다" + 보상이 아직 산정되지 않은 에포크를 조회하면 `Rewards calculation is not finalized yet`이 반환됩니다. 더 오래된 에포크를 조회하세요. + +--- + +## 늦게 설정한 경우 + +보상은 수신자 설정 여부와 관계없이 기여한 모든 에포크에 대해 산정됩니다. 이 보상은 소각되지 않으며 만료되지도 않습니다. 누군가가 지급을 제출할 때까지 해당 에포크의 분배 계정에 남아 있습니다. + +문제는 사후에 자동으로 제출해 주는 것이 없다는 점입니다. 정기 지급 프로세스는 최근 에포크를 처리하므로, 수신자 목록이 비어 있는 동안 지나간 에포크는 수동으로 제출하기 전까지 미지급 상태로 남습니다. + +영향을 받는 에포크를 찾으려면 기여자 코드가 있는 행 중 `distributed`가 `no`이고 보상이 0보다 큰 행을 찾으세요: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +지급 제출은 권한 없이 누구나 할 수 있으므로, 수신자가 설정된 후에는 잔액이 있는 아무 지갑이나(본인 지갑 포함) 수행할 수 있습니다: + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +전송하지 않고 시뮬레이션하려면 먼저 `--dry-run`을 추가하세요. 이 명령은 해당 에포크의 모든 기여자를 처리하고 이미 지급된 것은 건너뛰므로 안전하게 실행할 수 있습니다. + +직접 하고 싶지 않다면 DZF에 해당 에포크의 제출을 요청하세요. + +--- + +## 수신자 나중에 변경하기 + +언제든지 [3단계](#step-3-set-your-recipient-wallets)를 반복하세요. 새 목록이 기존 목록을 완전히 대체하므로, 추가하는 수신자뿐만 아니라 유지하려는 모든 수신자를 포함하세요. 비율은 다시 합계가 100이어야 합니다. + +추가하는 모든 지갑에 대해 [4단계](#step-4-check-each-recipient-can-hold-2z)를 확인하세요. + +--- + +## 보상 관리자 키 잠금 + +기본적으로 DZF는 보상 관리자 키를 변경할 수 있으며, 이는 키에 대한 접근 권한을 잃었을 때 유용합니다. 이를 차단하고 싶다면 다음과 같이 잠글 수 있습니다: + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "분실할 수 있는 키를 잠그지 마세요" + 관리가 차단되면 DZF를 포함하여 아무도 보상 관리자 키를 교체할 수 없습니다. 이후 해당 키를 분실하면 보상 전송 대상을 더 이상 변경할 수 없습니다. 키가 백업되어 있고 안전한 경우에만 잠그세요. + +다시 허용하려면 동일한 명령에 `--allow-protocol-management`을 사용하세요. + +--- + +## 문제 해결 + +**`manager` 열이 비어 있음.** +DZF가 아직 보상 관리자 키를 등록하지 않았습니다. 공개 키를 보내고 확인을 요청하세요. + +**`Invalid rewards manager`.** +서명에 사용한 키페어가 등록된 보상 관리자가 아닙니다. `-k`에 올바른 파일을 전달했는지, 또는 포털에서 올바른 지갑을 사용했는지 확인하세요. + +**`Invalid recipients`.** +비율의 합계가 정확히 100이 아니거나, 수신자가 8개를 초과했거나, 수신자 중 0% 지분이 있습니다. + +**보상이 적립되었으나 아무것도 도착하지 않음.** +두 가지 일반적인 원인이 있습니다. 수신자가 설정되지 않아 보낼 곳이 없거나, 수신 지갑에 2Z 토큰 계정이 없는 경우입니다. [4단계](#step-4-check-each-recipient-can-hold-2z)와 [5단계](#step-5-verify)를 확인하세요. 문제가 해결되면 이후 에포크는 자동으로 지급됩니다. 이미 지나간 에포크는 [수동 지급](#if-you-set-this-up-late)이 필요합니다. + +**최근 에포크의 보상이 0임.** +보상에는 약 10 DZ 에포크의 지연이 있습니다. 최소 그 이상 경과한 에포크를 확인하세요. 간헐적인 0 에포크도 정상입니다. [보상 도착 시점](#when-rewards-arrive)을 참조하세요. + +--- + +## 다음 단계 + +[온보딩 체크리스트](contribute-overview.md#onboarding-checklist)로 돌아가거나, [운영](contribute-operations.md)으로 진행하세요. \ No newline at end of file diff --git a/docs/contribute-rewards.pt.md b/docs/contribute-rewards.pt.md new file mode 100644 index 0000000..6e36ea2 --- /dev/null +++ b/docs/contribute-rewards.pt.md @@ -0,0 +1,292 @@ +--- +description: Configure a gestão de recompensas para que as recompensas em 2Z obtidas pela sua contribuição ao DoubleZero sejam pagas nas carteiras que você controla. +--- + +# Gestão de Recompensas + +Você ganha recompensas em [2Z](glossary.md#2z-token) pela largura de banda e dispositivos que contribui. O protocolo paga essas recompensas por conta própria, diretamente nas carteiras que você indicar. Até que você as indique, nada poderá ser pago. + +!!! warning "Faça isso durante a configuração da conta" + Configure a gestão de recompensas na [Fase 2: Configuração da Conta](contribute-provisioning.md#phase-2-account-setup), antes que seu dispositivo transporte tráfego. + + Suas recompensas ainda acumulam se você deixar isso para depois. O protocolo não as queima e elas não expiram. O que você perde é o pagamento automático: o processo de pagamento rotineiro percorre as épocas recentes, então qualquer época que passe enquanto você não tiver destinatários configurados terá que ser paga manualmente depois. Veja [Se Você Configurar Isso com Atraso](#se-voce-configurar-isso-com-atraso). + +--- + +## Como Funciona + +Três chaves estão envolvidas. Cada uma tem uma função diferente, e é mais seguro mantê-las separadas. + +| Chave | O que faz | Recebe recompensas? | +|-------|-----------|---------------------| +| **Chave de serviço** | Identifica você como contribuidor e assina seus comandos CLI. Também nomeia sua conta de recompensas onchain. | Não | +| **Chave do gerenciador de recompensas** | Assina alterações na lista de carteiras que recebem recompensas. | Não | +| **Carteira(s) destinatária(s)** | Mantém os 2Z que o protocolo envia a você. Até 8 carteiras. | Sim | + +A DoubleZero Foundation registra sua chave do gerenciador de recompensas vinculada à sua chave de serviço. Apenas a DZF pode fazer isso. Depois disso, apenas sua chave do gerenciador de recompensas pode alterar a lista de destinatários, e a DZF não pode redirecionar suas recompensas. + +```mermaid +flowchart LR + DZF["DZF"] -->|"Registra sua
chave do gerenciador de recompensas"| ACC["Sua conta de recompensas
onchain"] + RM["Chave do gerenciador de recompensas
(você mantém, guarde offline)"] -->|"Define destinatários
e percentuais"| ACC + ACC --> R1["Carteira destinatária 1"] + ACC --> R2["Carteira destinatária 2"] + PROTO["Protocolo paga
a cada época DZ"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## O Que Você Precisa Primeiro + +- Uma conta de contribuidor onchain. Verifique com `doublezero contributor list`. +- Uma carteira Solana para atuar como seu gerenciador de recompensas, com cerca de 0,01 SOL para pagar taxas de transação. +- Uma ou mais carteiras para receber os 2Z. +- O CLI `doublezero-solana`, se você quiser usar a linha de comando em vez do portal. Instale com `sudo apt update && sudo apt install doublezero-solana`. + +!!! tip "Use uma carteira de hardware para a chave do gerenciador de recompensas" + A chave do gerenciador de recompensas controla para onde seu dinheiro vai. Mantenha-a em uma carteira de hardware ou de outra forma offline. Ela nunca precisa ficar em um servidor, e nunca mantém suas recompensas. + +--- + +## Passo 1: Crie Sua Carteira do Gerenciador de Recompensas + +Crie uma carteira Solana que você controle e com a qual possa assinar. Pode ser uma carteira de hardware, uma carteira de navegador ou um arquivo de par de chaves. + +Financie-a com uma pequena quantidade de SOL, cerca de 0,01 SOL. Isso serve apenas para pagar taxas de rede quando você alterar sua lista de destinatários. + +Não reutilize sua chave de serviço para isso. Se a chave de serviço estiver em um servidor de gerenciamento, qualquer pessoa que acessar esse servidor poderá redirecionar suas recompensas. + +--- + +## Passo 2: Envie a Chave Pública para a DZF + +Forneça à DZF a **chave pública** da sua carteira do gerenciador de recompensas. Nunca compartilhe a chave privada. + +A DZF a registra vinculada à sua chave de serviço onchain e confirma quando estiver concluído. Você não pode fazer este passo sozinho. + +!!! tip "Envie junto com sua chave de serviço" + Se você está seguindo o [Guia de Provisionamento de Dispositivos](contribute-provisioning.md), envie esta chave pública ao mesmo tempo que sua chave de serviço e nome de usuário do GitHub, no [Passo 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). A DZF registra as duas chaves em transações separadas, então enviá-las juntas economiza uma ida e volta. + +Você pode verificar se foi registrada: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +A coluna `manager` mostra sua chave do gerenciador de recompensas. Se estiver vazia, a DZF ainda não a registrou. + +--- + +## Passo 3: Defina Suas Carteiras Destinatárias + +Agora indique para onde as recompensas devem ir. Você pode usar o portal web ou o CLI. Ambos gravam a mesma coisa onchain. + +Regras que se aplicam em ambos os casos: + +- No máximo 8 carteiras destinatárias. +- Os percentuais devem ser números inteiros e devem somar exatamente 100. +- Um destinatário não pode ter uma participação de 0%. Remova-o em vez disso. + +!!! info "Se seu acordo com a DZF inclui compartilhamento de receita" + Alguns contribuidores têm um acordo que divide as recompensas com a fundação, por exemplo quando a DZF forneceu o hardware. Se isso se aplica a você, a DZF fornece o endereço e o percentual a inserir aqui. Pergunte à DZF se não tiver certeza. + +=== "Portal web" + + 1. Acesse [doublezero.xyz/rewards](https://doublezero.xyz/rewards). O endereço antigo, `rewards.doublezero.xyz`, redireciona para cá. + 2. Conecte sua carteira do gerenciador de recompensas com o botão de carteira no canto superior direito. + 3. Selecione sua chave de serviço na lista da página seguinte. + 4. Insira cada endereço de carteira destinatária e seu percentual. O total deve ser 100%. + 5. Clique em **Submit** e aprove a transação na sua carteira. + +=== "CLI" + + Execute isso com seu par de chaves do gerenciador de recompensas como `-k`. Repita `--recipient` para cada carteira. + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | Flag | Descrição | + |------|-----------| + | `--service-key` | Sua chave de serviço de contribuidor. Ela nomeia a conta de recompensas onchain. | + | `--recipient` | Um destinatário no formato `PUBKEY:PERCENT`. Números inteiros, de 1 a 100, somando 100. Máximo de 8. | + | `-k` | Seu par de chaves do gerenciador de recompensas. A transação falha se este não for o gerenciador de recompensas registrado. | + | `-u` | `mainnet-beta`. | + + Adicione `--dry-run` primeiro se quiser simular a transação sem enviá-la. + +--- + +## Passo 4: Verifique Se Cada Destinatário Pode Manter 2Z + +O protocolo envia 2Z com uma transferência de token simples. Ele **não** cria a conta de token para você. Se uma carteira destinatária não tiver uma conta de token 2Z, o pagamento daquela época falha. + +O mint do 2Z na mainnet é: + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +Liste as contas de token que uma carteira já possui: + +```bash +spl-token accounts --owner -u m +``` + +Se `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` não estiver nessa lista, crie a conta uma vez: + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +Qualquer carteira financiada pode pagar por isso. Custa uma pequena quantidade de SOL e só precisa ser feito uma vez por carteira destinatária. + +!!! note "Carteiras que já possuem 2Z estão ok" + Se a carteira já recebeu 2Z alguma vez, a conta de token existe e você pode pular este passo. + +--- + +## Passo 5: Verifique + +Confira o que está agora registrado onchain: + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +Exemplo de saída: + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +A coluna `ata` é a conta de token 2Z na qual cada destinatário será pago. Verifique se a coluna `proportion` soma 100%. + +--- + +## Quando as Recompensas Chegam + +- As recompensas são calculadas por **época DZ**, que é a época do DoubleZero Ledger. Uma época DZ dura aproximadamente dois dias. +- O pagamento de uma época acontece cerca de 10 épocas DZ após o término daquela época, ou seja, aproximadamente 20 dias depois. Esse atraso cobre a contabilidade da época. +- Os pagamentos são automáticos. Você não precisa reivindicá-los e não precisa executar nada. +- Uma vez que seus destinatários estejam configurados, os pagamentos começam a chegar dentro de alguns dias conforme as próximas épocas são processadas. Épocas que passaram antes de você configurar seus destinatários são um assunto separado, veja [Se Você Configurar Isso com Atraso](#se-voce-configurar-isso-com-atraso). +- Uma época DZ e uma época Solana não têm a mesma duração. Essa diferença se acumula ao longo do tempo, então de vez em quando uma época DZ mostra zero recompensas. Isso é esperado. + +--- + +## Onde Ver Suas Recompensas + +**Visão agregada.** O [Economic Hub](https://doublezero.xyz/economic-hub) mostra as recompensas dos contribuidores em nível de rede. + +**Por época.** Pergunte ao protocolo o que uma determinada época DZ pagou: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +A saída lista cada contribuidor com sua participação, sua recompensa em 2Z e se o pagamento foi realizado. Encontre seu código de contribuidor na coluna `contributor`. + +Para ver em qual época DZ a rede está agora, omita `-e`: + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "Épocas recentes ainda não estão finalizadas" + Consultar uma época cujas recompensas ainda não foram calculadas retorna `Rewards calculation is not finalized yet`. Tente uma época mais antiga. + +--- + +## Se Você Configurar Isso com Atraso + +As recompensas são calculadas para cada época em que você contribuiu, independentemente de ter destinatários configurados no momento. Essas recompensas não são queimadas e não expiram. Elas ficam na conta de distribuição daquela época até que alguém submeta o pagamento. + +O problema é que nada as submete por você depois do fato. O processo de pagamento rotineiro percorre épocas recentes, então uma época que passou enquanto sua lista de destinatários estava vazia permanece sem pagamento até ser submetida manualmente. + +Para descobrir quais épocas foram afetadas, procure linhas com seu código de contribuidor onde `distributed` é `no` e a recompensa é maior que zero: + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +Submeter o pagamento é permissionless, então uma vez que seus destinatários estejam configurados, qualquer carteira financiada pode fazer isso, incluindo a sua: + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +Adicione `--dry-run` primeiro para simular sem enviar nada. O comando percorre todos os contribuidores daquela época e pula os que já foram pagos, então é seguro executá-lo. + +Se você preferir não fazer isso sozinho, peça à DZF para submeter as épocas por você. + +--- + +## Alterando Destinatários Posteriormente + +Repita o [Passo 3](#passo-3-defina-suas-carteiras-destinatarias) a qualquer momento. A nova lista substitui a antiga completamente, então inclua todos os destinatários que você ainda deseja, não apenas os que está adicionando. Os percentuais devem somar 100 novamente. + +Lembre-se do [Passo 4](#passo-4-verifique-se-cada-destinatario-pode-manter-2z) para qualquer carteira que adicionar. + +--- + +## Bloqueando a Chave do Gerenciador de Recompensas + +Por padrão, a DZF pode alterar sua chave do gerenciador de recompensas, o que é útil caso você perca o acesso a ela. Se você preferir descartar essa possibilidade, pode bloqueá-la: + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "Não bloqueie uma chave que você pode perder" + Uma vez que o gerenciamento é bloqueado, ninguém pode substituir sua chave do gerenciador de recompensas, incluindo a DZF. Se você então perder essa chave, não poderá mais alterar para onde suas recompensas vão. Só bloqueie se a chave estiver com backup e segura. + +Para permitir novamente, execute o mesmo comando com `--allow-protocol-management`. + +--- + +## Solução de Problemas + +**A coluna `manager` está vazia.** +A DZF ainda não registrou sua chave do gerenciador de recompensas. Envie a chave pública e peça confirmação. + +**`Invalid rewards manager`.** +O par de chaves com o qual você assinou não é o gerenciador de recompensas registrado. Verifique se passou o arquivo correto para `-k`, ou a carteira correta no portal. + +**`Invalid recipients`.** +Seus percentuais não somam exatamente 100, você listou mais de 8 destinatários, ou um deles tem participação de 0%. + +**As recompensas aparecem como ganhas, mas nada chega.** +Duas causas comuns. Ou nenhum destinatário está configurado, então não há para onde enviá-las, ou uma carteira destinatária não possui conta de token 2Z. Siga o [Passo 4](#passo-4-verifique-se-cada-destinatario-pode-manter-2z) e o [Passo 5](#passo-5-verifique). Uma vez corrigido, épocas futuras serão pagas automaticamente. Épocas que já passaram precisam de [pagamento manual](#se-voce-configurar-isso-com-atraso). + +**Suas recompensas para uma época recente são 0.** +As recompensas têm um atraso de cerca de 10 épocas DZ. Verifique uma época que tenha pelo menos essa idade. Épocas ocasionais com zero também são normais, veja [Quando as Recompensas Chegam](#quando-as-recompensas-chegam). + +--- + +## Próximos Passos + +Volte para a [Lista de Verificação de Integração](contribute-overview.md#onboarding-checklist), ou prossiga para [Operações](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.zh.md b/docs/contribute-rewards.zh.md new file mode 100644 index 0000000..33ca286 --- /dev/null +++ b/docs/contribute-rewards.zh.md @@ -0,0 +1,292 @@ +--- +description: 设置奖励管理，以便您通过 DoubleZero 贡献所赚取的 2Z 奖励支付到您控制的钱包。 +--- + +# 奖励管理 + +您通过贡献带宽和设备赚取 [2Z](glossary.md#2z-token) 奖励。协议会自动将这些奖励直接支付到您指定的钱包。在您指定钱包之前，奖励无法支付。 + +!!! warning "请在账户设置期间完成此操作" + 请在 [阶段 2：账户设置](contribute-provisioning.md#phase-2-account-setup) 中设置奖励管理，在您的设备开始承载流量之前完成。 + + 如果您推迟此操作，奖励仍会累积。协议不会销毁它们，它们也不会过期。您损失的是自动支付：常规支付流程只处理近期的纪元，因此在您未设置收款方期间经过的任何纪元都需要事后手动支付。请参阅 [如果您设置较晚](#if-you-set-this-up-late)。 + +--- + +## 工作原理 + +涉及三个密钥。每个密钥执行不同的功能，将它们分开保管更为安全。 + +| 密钥 | 功能 | 是否接收奖励？ | +|-----|------|---------------| +| **服务密钥** | 标识您的贡献者身份并签署您的 CLI 命令。同时在链上命名您的奖励账户。 | 否 | +| **奖励管理密钥** | 签署对接收奖励的钱包列表的更改。 | 否 | +| **收款钱包** | 持有协议发送给您的 2Z。最多 8 个钱包。 | 是 | + +DoubleZero 基金会将您的奖励管理密钥注册到您的服务密钥上。只有 DZF 能执行此操作。此后，只有您的奖励管理密钥可以更改收款方列表，DZF 无法重定向您的奖励。 + +```mermaid +flowchart LR + DZF["DZF"] -->|"注册您的
奖励管理密钥"| ACC["您的链上
奖励账户"] + RM["奖励管理密钥
（由您持有，保持离线）"] -->|"设置收款方
和百分比"| ACC + ACC --> R1["收款钱包 1"] + ACC --> R2["收款钱包 2"] + PROTO["协议按每个
DZ 纪元支付"] -->|"2Z"| R1 + PROTO -->|"2Z"| R2 +``` + +--- + +## 前置条件 + +- 链上贡献者账户。使用 `doublezero contributor list` 检查。 +- 一个 Solana 钱包作为您的奖励管理器，持有约 0.01 SOL 用于支付交易费用。 +- 一个或多个用于接收 2Z 的钱包。 +- `doublezero-solana` CLI，如果您想使用命令行而非门户网站。使用 `sudo apt update && sudo apt install doublezero-solana` 安装。 + +!!! tip "为奖励管理密钥使用硬件钱包" + 奖励管理密钥控制着您的资金流向。请将其保存在硬件钱包上或以其他方式保持离线。它无需存放在服务器上，也不持有您的奖励。 + +--- + +## 步骤 1：创建您的奖励管理钱包 + +创建一个您控制且可以签名的 Solana 钱包。可以是硬件钱包、浏览器钱包或密钥对文件。 + +充入少量 SOL，约 0.01 SOL。这仅用于在您更改收款方列表时支付网络费用。 + +不要复用您的服务密钥。如果服务密钥存放在管理服务器上，任何能访问该服务器的人都可能重定向您的奖励。 + +--- + +## 步骤 2：将公钥发送给 DZF + +将您奖励管理钱包的**公钥**提供给 DZF。切勿分享私钥。 + +DZF 会将其注册到您的链上服务密钥，并在完成后确认。您无法自行完成此步骤。 + +!!! tip "与服务密钥一起发送" + 如果您正在按照 [设备配置指南](contribute-provisioning.md) 操作，请在 [步骤 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf) 中将此公钥与您的服务密钥和 GitHub 用户名一起发送。DZF 在不同的交易中注册这两个密钥，因此一起发送可以减少一次往返。 + +您可以检查是否已注册成功： + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + -u mainnet-beta +``` + +`manager` 列显示您的奖励管理密钥。如果为空，说明 DZF 尚未注册。 + +--- + +## 步骤 3：设置您的收款钱包 + +现在指定奖励的发送目标。您可以使用网页门户或 CLI。两者在链上写入的内容相同。 + +无论哪种方式都适用的规则： + +- 最多 8 个收款钱包。 +- 百分比必须为整数，且总和必须恰好为 100。 +- 收款方不能有 0% 的份额。请改为移除它。 + +!!! info "如果您与 DZF 的协议包含收入分成" + 部分贡献者的协议中约定与基金会分成奖励，例如 DZF 提供了硬件的情况。如果这适用于您，DZF 会提供需要在此处输入的地址和百分比。如果不确定，请咨询 DZF。 + +=== "网页门户" + + 1. 前往 [doublezero.xyz/rewards](https://doublezero.xyz/rewards)。旧地址 `rewards.doublezero.xyz` 会重定向到此处。 + 2. 使用右上角的钱包按钮连接您的奖励管理钱包。 + 3. 在下一页面的列表中选择您的服务密钥。 + 4. 输入每个收款钱包地址及其百分比。总计必须为 100%。 + 5. 点击 **Submit** 并在钱包中批准交易。 + +=== "CLI" + + 使用您的奖励管理密钥对作为 `-k` 运行此命令。为每个钱包重复 `--recipient`。 + + ```bash + doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --recipient :70 \ + --recipient :30 \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta + ``` + + | 标志 | 说明 | + |------|------| + | `--service-key` | 您的贡献者服务密钥。它在链上命名奖励账户。 | + | `--recipient` | 格式为 `PUBKEY:PERCENT` 的收款方。整数，1 到 100，总和为 100。最多 8 个。 | + | `-k` | 您的奖励管理密钥对。如果这不是已注册的奖励管理器，交易将失败。 | + | `-u` | `mainnet-beta`。 | + + 如果您想在不发送交易的情况下模拟，请先添加 `--dry-run`。 + +--- + +## 步骤 4：检查每个收款方是否可以持有 2Z + +协议通过普通代币转账发送 2Z。它**不会**为您创建代币账户。如果收款钱包没有 2Z 代币账户，该纪元的支付将失败。 + +主网上的 2Z 铸造地址为： + +``` +J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd +``` + +列出钱包已有的代币账户： + +```bash +spl-token accounts --owner -u m +``` + +如果 `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` 不在列表中，创建一次该账户： + +```bash +spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ + --owner \ + --fee-payer /path/to/any-funded-keypair.json \ + -u m +``` + +任何有资金的钱包都可以为此付费。费用为少量 SOL，每个收款钱包只需执行一次。 + +!!! note "已持有 2Z 的钱包无需操作" + 如果该钱包曾经接收过 2Z，代币账户已存在，您可以跳过此步骤。 + +--- + +## 步骤 5：验证 + +检查链上当前记录的内容： + +```bash +doublezero-solana revenue-distribution fetch contributor-rewards \ + --service-key \ + --view recipients \ + -u mainnet-beta +``` + +示例输出： + +``` +| index | recipient | ata | proportion | +|-------|----------------------------------------------|----------------------------------------------|------------| +| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | +| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | +``` + +`ata` 列是每个收款方将收到支付的 2Z 代币账户。检查 `proportion` 列的总和是否为 100%。 + +--- + +## 奖励何时到账 + +- 奖励按 **DZ 纪元** 计算，即 DoubleZero 账本的纪元。一个 DZ 纪元大约运行两天。 +- 某个纪元的支付大约在该纪元结束后 10 个 DZ 纪元发生，即大约 20 天后。此延迟用于完成该纪元的核算。 +- 支付是自动的。您无需领取，也无需运行任何程序。 +- 一旦设置了收款方，支付将在几天内开始到账，随着下一批纪元被处理。在您设置收款方之前已经过去的纪元属于另一种情况，请参阅 [如果您设置较晚](#if-you-set-this-up-late)。 +- DZ 纪元和 Solana 纪元的长度不同。这种差异会随时间累积，因此偶尔某个 DZ 纪元会显示零奖励。这是正常现象。 + +--- + +## 在哪里查看您的奖励 + +**汇总视图。** [Economic Hub](https://doublezero.xyz/economic-hub) 在网络层面显示贡献者奖励。 + +**按纪元查看。** 查询协议在某个 DZ 纪元的支付情况： + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +输出列出每个贡献者及其份额、2Z 奖励金额以及是否已支付。在 `contributor` 列中找到您的贡献者代码。 + +要查看网络当前所在的 DZ 纪元，省略 `-e`： + +```bash +doublezero-solana revenue-distribution fetch distribution -u mainnet-beta +``` + +!!! note "近期纪元尚未最终确定" + 查询奖励尚未计算完成的纪元会返回 `Rewards calculation is not finalized yet`。请尝试查询更早的纪元。 + +--- + +## 如果您设置较晚 + +无论您在当时是否配置了收款方，您贡献的每个纪元的奖励都会被计算。这些奖励不会被销毁，也不会过期。它们保存在该纪元的分配账户中，直到有人提交支付。 + +问题在于事后没有人会自动为您提交。常规支付流程只处理近期纪元，因此在您的收款方列表为空时经过的纪元将保持未支付状态，直到手动提交。 + +要查找受影响的纪元，查找您的贡献者代码对应的行，其中 `distributed` 为 `no` 且奖励大于零： + +```bash +doublezero-solana revenue-distribution fetch distribution \ + -e --view rewards -u mainnet-beta +``` + +提交支付是无需许可的，因此一旦您配置了收款方，任何有资金的钱包都可以执行此操作，包括您自己的： + +```bash +doublezero-solana revenue-distribution relay distribute-rewards \ + -e -k /path/to/funded-keypair.json -u mainnet-beta +``` + +先添加 `--dry-run` 可以在不发送任何内容的情况下模拟。该命令会处理该纪元中的每个贡献者并跳过已支付的，因此运行是安全的。 + +如果您不想自己操作，可以请 DZF 为您提交这些纪元。 + +--- + +## 稍后更改收款方 + +随时重复 [步骤 3](#step-3-set-your-recipient-wallets)。新列表会完全替换旧列表，因此请包含您仍然需要的所有收款方，而不仅仅是新增的。百分比必须再次总和为 100。 + +对于您添加的任何钱包，请记得执行 [步骤 4](#step-4-check-each-recipient-can-hold-2z)。 + +--- + +## 锁定奖励管理密钥 + +默认情况下，DZF 可以更改您的奖励管理密钥，这在您丢失访问权限时很有用。如果您希望排除这种可能性，可以阻止它： + +```bash +doublezero-solana revenue-distribution configure-contributor-rewards \ + --service-key \ + --block-protocol-management \ + -k /path/to/rewards-manager-keypair.json \ + -u mainnet-beta +``` + +!!! danger "不要锁定可能丢失的密钥" + 一旦管理被阻止，任何人都无法替换您的奖励管理密钥，包括 DZF。如果您随后丢失该密钥，您将无法再更改奖励的发送目标。仅在密钥已备份且安全的情况下才执行锁定。 + +要重新允许，请使用 `--allow-protocol-management` 运行相同的命令。 + +--- + +## 故障排除 + +**`manager` 列为空。** +DZF 尚未注册您的奖励管理密钥。将公钥发送给他们并请求确认。 + +**`Invalid rewards manager`。** +您用于签名的密钥对不是已注册的奖励管理器。检查您是否向 `-k` 传递了正确的文件，或在门户中使用了正确的钱包。 + +**`Invalid recipients`。** +您的百分比总和不恰好为 100，您列出了超过 8 个收款方，或者其中一个的份额为 0%。 + +**奖励显示已赚取但未收到。** +两个常见原因。要么未配置收款方，因此没有发送目标；要么收款钱包没有 2Z 代币账户。请按照 [步骤 4](#step-4-check-each-recipient-can-hold-2z) 和 [步骤 5](#step-5-verify) 进行排查。修复后，未来的纪元会自动支付。已经过去的纪元需要 [手动支付](#if-you-set-this-up-late)。 + +**您近期纪元的奖励为 0。** +奖励有大约 10 个 DZ 纪元的延迟。请检查至少那么久之前的纪元。偶尔出现零奖励纪元也是正常的，请参阅 [奖励何时到账](#when-rewards-arrive)。 + +--- + +## 后续步骤 + +返回 [入门检查清单](contribute-overview.md#onboarding-checklist)，或继续前往 [运维](contribute-operations.md)。 \ No newline at end of file diff --git a/docs/contribute.es.md b/docs/contribute.es.md index ad903d5..fc2804a 100644 --- a/docs/contribute.es.md +++ b/docs/contribute.es.md @@ -1,16 +1,18 @@ -# Requisitos y Arquitectura para Contribuidores -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Requisitos de hardware, ancho de banda y conectividad, así como arquitectura para contribuir capacidad a la red DoubleZero. +--- +# Requisitos y Arquitectura para Contribuidores ## Resumen -Cualquier persona que desee monetizar sus cables de fibra óptica y hardware de red subutilizados puede contribuir a la red DoubleZero. Los contribuidores de red deben proporcionar ancho de banda dedicado entre dos puntos, operar dispositivos compatibles con DoubleZero (DZDs) en cada extremo, y una conexión a internet pública en cada extremo. Los contribuidores de red también deben ejecutar software DoubleZero en cada DZD para proporcionar servicios como multicast, búsqueda de usuarios y filtrado de borde. +Cualquier persona que desee monetizar sus cables de fibra óptica y hardware de red subutilizados puede contribuir a la red DoubleZero. Los contribuidores de red deben proporcionar ancho de banda dedicado entre dos puntos, operar dispositivos compatibles con DoubleZero (DZDs) en cada extremo, y una conexión a internet pública en cada extremo. Los contribuidores de red también deben ejecutar el software de DoubleZero en cada DZD para proporcionar servicios como multicast, búsqueda de usuarios y filtrado en el borde. -El contrato inteligente de DoubleZero es la piedra angular para garantizar que la red mantenga enlaces de alta calidad que puedan medirse e integrarse en la topología, permitiendo a nuestros controladores de red desarrollar la ruta más eficiente de extremo a extremo entre nuestros diferentes usuarios y puntos finales. Tras la ejecución del contrato inteligente y el despliegue del equipo de red y el ancho de banda, una entidad se clasifica como contribuidor de red. Consulte [Economía de DoubleZero](https://economics.doublezero.xyz/overview) para comprender mejor la economía detrás de participar en DoubleZero como contribuidor de red. +El contrato inteligente de DoubleZero es la piedra angular para garantizar que la red mantenga enlaces de alta calidad que puedan medirse e integrarse en la topología, permitiendo que nuestros controladores de red desarrollen la ruta de extremo a extremo más eficiente entre nuestros diferentes usuarios y puntos finales. Tras la ejecución del contrato inteligente y el despliegue del equipo de red y el ancho de banda, una entidad se clasifica como contribuidor de red. Consulte [Economía de DoubleZero](https://economics.doublezero.xyz/overview) para comprender mejor la economía detrás de participar en DoubleZero como contribuidor de red. --- -## Requisitos para ser Contribuidor de Red DoubleZero +## Requisitos para ser un Contribuidor de Red DoubleZero - Ancho de banda dedicado que pueda proporcionar conectividad IPv4 y un MTU de 2048 bytes entre dos centros de datos - Hardware de Dispositivo DoubleZero (DZD) compatible con el protocolo DoubleZero @@ -19,11 +21,11 @@ El contrato inteligente de DoubleZero es la piedra angular para garantizar que l ## Guía de Inicio Rápido -Como contribuidor de red, la forma más sencilla de comenzar en DoubleZero es identificando capacidad en su red que pueda dedicarse a DoubleZero. Una vez identificados, los DZDs deben desplegarse, facilitando la red superpuesta DoubleZero que solo requiere alcanzabilidad IPv4 y un MTU mínimo de 2048 bytes como dependencias de la red del contribuidor. +Como contribuidor de red, la forma más sencilla de comenzar en DoubleZero es identificando capacidad en su red que pueda dedicarse a DoubleZero. Una vez identificada, los DZDs deben desplegarse, facilitando la red superpuesta de DoubleZero que solo requiere conectividad IPv4 y un MTU mínimo de 2048 bytes como dependencias de la red del contribuidor. -La Figura 1 destaca el modelo más simple para contribuir con ancho de banda y servicios de envío y procesamiento de paquetes. Se despliega un DZD en cada centro de datos, interactuando con la red interna del contribuidor de red para proporcionar conectividad WAN de DoubleZero. Esto se complementa con internet local, típicamente una solución de Acceso Directo a Internet (DIA), que se usa como rampas de acceso para los usuarios de DoubleZero. Si bien se espera que DIA sea la opción preferida para facilitar el acceso a los usuarios de DoubleZero, son posibles numerosos modelos de conectividad, por ejemplo, cableado físico a servidores, extensión de fabric de red, etc. Nos referimos a estas opciones como Elige Tu Propia Aventura (CYOA), proporcionando al contribuidor flexibilidad para conectar usuarios locales o remotos de una manera que mejor se adapte a sus políticas de red internas. +La Figura 1 destaca el modelo más simple para contribuir ancho de banda y servicios de envío y procesamiento de paquetes. Se despliega un DZD en cada centro de datos, interfazando con la red interna del contribuidor para proporcionar conectividad WAN de DoubleZero. Esto se complementa con internet local, típicamente una solución de Acceso Directo a Internet (DIA), que se utiliza como puntos de acceso para los usuarios de DoubleZero. Si bien se espera que DIA sea la opción preferida para facilitar el acceso a los usuarios de DoubleZero, son posibles numerosos modelos de conectividad, por ejemplo, cableado físico a servidores, extensión de fabric de red, etc. Nos referimos a estas opciones como Elige Tu Propia Aventura (CYOA), proporcionando al contribuidor flexibilidad para conectar usuarios locales o remotos de la manera que mejor se adapte a sus políticas de red internas. -Como con cualquier red, la alcanzabilidad es una parte fundamental de la arquitectura, ya que los contribuidores de red no pueden vivir en aislamiento. Como tal, el DZD *debe* tener un enlace a un Exchange DoubleZero (DZX) para crear una red contigua entre los participantes. +Como con cualquier red, la alcanzabilidad es una parte fundamental de la arquitectura, ya que los contribuidores de red no pueden vivir aislados. Por lo tanto, el DZD *debe* tener un enlace a un DoubleZero Exchange (DZX) para crear una red contigua entre los participantes.
![Image title](images/figure1.png){ width="800" } @@ -32,9 +34,9 @@ Como con cualquier red, la alcanzabilidad es una parte fundamental de la arquite ### Ejemplos de Contribuciones -Las formas en que un contribuidor de red puede hacer crecer sus contribuciones a DoubleZero son muchas, incluyendo: +Las formas en que un contribuidor de red puede ampliar sus contribuciones a DoubleZero son muchas, incluyendo: -- Mejorar las características de rendimiento de sus contribuciones existentes: aumentar el ancho de banda, reducir la latencia +- Mejorar las características de rendimiento de sus contribuciones existentes: aumentar ancho de banda, reducir latencia - Agregar múltiples enlaces entre los mismos centros de datos - Agregar un nuevo enlace desde un centro de datos existente a un nuevo centro de datos - Agregar un nuevo enlace independiente entre dos nuevos centros de datos @@ -45,20 +47,20 @@ Las formas en que un contribuidor de red puede hacer crecer sus contribuciones a
Figura 2: Contribución de Ancho de Banda de Red DoubleZero Entre 3 Centros de Datos - Contribuidor Único
-Un solo DZD puede soportar múltiples enlaces contribuidos a DoubleZero. La Figura 2 ilustra una topología potencial si un solo centro de datos, denominado 1, termina el ancho de banda hacia dos centros de datos remotos diferentes, 2 y 3. En este escenario, cada centro de datos contiene solo 1 DZD. Todos los DZDs utilizan DIA para las rampas de acceso de usuarios como su interfaz CYOA. +Un solo DZD puede soportar múltiples enlaces contribuidos a DoubleZero. La Figura 2 ilustra una topología potencial si un solo centro de datos, denominado como 1, termina ancho de banda hacia dos centros de datos remotos diferentes, 2 y 3. En este escenario, cada centro de datos contiene solo 1 DZD. Todos los DZDs utilizan DIA para puntos de acceso de usuarios como su interfaz CYOA. #### Ejemplo 2: Contribuidor Único, 3 Centros de Datos, Tres Enlaces -La Figura 3 describe la topología de DoubleZero cuando un único contribuidor despliega tres enlaces en una topología triangular entre 3 centros de datos. En un escenario similar al ejemplo 1, se despliega un único DZD en los centros de datos 1, 2 y 3, cada uno soportando 2 enlaces de red independientes. La topología resultante es un triángulo o anillo entre los centros de datos. +La Figura 3 describe la topología de DoubleZero cuando un contribuidor único despliega tres enlaces en una topología triangular entre 3 centros de datos. En un escenario similar al ejemplo 1, se despliega un solo DZD en los centros de datos 1, 2 y 3, cada uno soportando 2 enlaces de red independientes. La topología resultante es un triángulo o anillo entre centros de datos.
![Image title](images/figure3.png){ width="800" }
Figura 3: Contribución de Ancho de Banda de Red DoubleZero Entre 3 Centros de Datos - Contribuidor Único
-### Exchange DoubleZero +### DoubleZero Exchange -La creación de una red contigua es un elemento fundamental de la arquitectura DoubleZero. Los contribuidores se interconectan a través de un Exchange DoubleZero (DZX) dentro de un área metropolitana, que es una ciudad como Nueva York (NYC), Londres (LON) o Tokio (TYO). Un DZX es un fabric de red similar a un Exchange de Internet, que permite el peering y el intercambio de rutas. +La creación de una red contigua es un bloque fundamental de la arquitectura de DoubleZero. Los contribuidores se interconectan a través de un DoubleZero Exchange (DZX) dentro de un área metropolitana, que es una ciudad como Nueva York (NYC), Londres (LON) o Tokio (TYO). Un DZX es un fabric de red similar a un Internet Exchange, que permite peering e intercambio de rutas. En la figura 4, el contribuidor de red 1 opera en los centros de datos 1, 2 y 3, mientras que el contribuidor de red 2 opera en los centros de datos 2, 4 y 5. Al interconectarse en el centro de datos 2, el alcance de la red DoubleZero aumenta a 5 centros de datos contiguos. @@ -69,13 +71,13 @@ En la figura 4, el contribuidor de red 1 opera en los centros de datos 1, 2 y 3, ### Opciones de Contribución de Ancho de Banda -DoubleZero requiere que un contribuidor de red ofrezca conectividad integrada mediante un perfil garantizado de ancho de banda, latencia y jitter entre DZDs en dos centros de datos terminales expresado a través de un contrato inteligente. DoubleZero no exige cómo un contribuidor de red implementa su contribución; sin embargo, en las siguientes secciones proporcionamos opciones indicativas para su uso a su sola discreción. +DoubleZero requiere que un contribuidor de red ofrezca conectividad integrada mediante un perfil garantizado de ancho de banda, latencia y jitter entre DZDs en dos centros de datos de terminación, expresado a través de un contrato inteligente. DoubleZero no establece cómo un contribuidor de red implementa su contribución; sin embargo, en las siguientes secciones proporcionamos opciones indicativas para uso a su entera discreción. -Las áreas importantes a considerar para un contribuidor de red podrían ser: +Áreas importantes a considerar para un contribuidor de red podrían ser: -- Capacidad de garantizar el rendimiento de la red del servicio DoubleZero: ancho de banda, latencia y jitter -- Segregación de sus servicios de red interna existentes -- Conflictos de direccionamiento IPv4, específicamente con el espacio de direcciones del underlay del túnel +- Capacidad de garantizar el rendimiento de red del servicio DoubleZero: ancho de banda, latencia y jitter +- Segregación de sus servicios de red internos existentes +- Conflictos de direccionamiento IPv4, específicamente con el espacio de direcciones del underlay de túnel - Tiempo de actividad y disponibilidad - Consideraciones de CAPEX y OPEX @@ -85,23 +87,23 @@ Las áreas importantes a considerar para un contribuidor de red podrían ser:
Figura 5: Servicios Ópticos de Capa 1
-El ancho de banda de Capa 1, descrito más formalmente como servicios de longitud de onda, puede ver capacidad dedicada aprovisionada en una infraestructura óptica existente, como DWDM, CWDM o mediante multiplexores ópticos (MUX). En la figura 5, los DZDs utilizan una óptica de color que se conecta a un MUX L1, que intercala la longitud de onda del DZD en una fibra oscura existente. +El ancho de banda de Capa 1, descrito más formalmente como servicios de longitud de onda, puede verse como capacidad dedicada aprovisionada sobre una infraestructura óptica existente, como DWDM, CWDM o mediante multiplexores ópticos (MUX). En la figura 5, los DZDs utilizan una óptica coloreada que se cablea a un MUX L1, el cual intercala la longitud de onda del DZD en una fibra oscura existente. -Esta solución tiene numerosos beneficios para los contribuidores de red que ya operan una red troncal existente. Los cambios operativos iterativos, así como los requisitos adicionales de CAPEX y OPEX, son modestos. Esta opción es particularmente robusta para ofrecer segregación de los servicios de red del contribuidor. +Esta solución tiene numerosos beneficios para los contribuidores de red que ya operan una red core existente. Los cambios operativos iterativos, así como los requisitos adicionales de CAPEX y OPEX, son modestos. Esta opción es particularmente robusta para ofrecer segregación de los servicios de red del contribuidor. -#### Ancho de Banda de Red Conmutada por Paquetes +#### Ancho de Banda de Conmutación de Paquetes -Las redes conmutadas por paquetes pueden considerarse una red empresarial típica, ejecutando protocolos estándar de enrutamiento y conmutación para soportar aplicaciones de negocios. Hay numerosas tecnologías de red que logran conectividad, por ejemplo, extensiones de capa 2 (L2) usando etiquetas VLAN. +Las redes de conmutación de paquetes pueden considerarse una red empresarial típica, ejecutando protocolos estándar de enrutamiento y conmutación que soportan aplicaciones de negocio. Existen numerosas tecnologías de red que logran conectividad, por ejemplo, extensiones de capa 2 (L2) utilizando etiquetas VLAN. ##### Extensión L2
![Image title](images/figure6.png){ width="800" } -
Figura 6: Redes Conmutadas por Paquetes - Extensión L2
+
Figura 6: Redes de Conmutación de Paquetes - Extensión L2
-Una extensión L2 como se muestra en la Figura 6 puede facilitarse mediante el etiquetado de VLAN. El puerto de un DZD puede conectarse al switch de red interna de un contribuidor, con el puerto del switch configurado como puerto de acceso en, por ejemplo, VLAN 10. Mediante el etiquetado 802.1q, esta VLAN puede llevarse a través de múltiples saltos de switch en la red del contribuidor, terminando en el switch que interactúa con el DZD remoto. +Una extensión L2 como se muestra en la Figura 6 puede facilitarse mediante etiquetado VLAN. El puerto de un DZD puede cablearse al switch de red interna del contribuidor, con el puerto del switch configurado como puerto de acceso en, por ejemplo, VLAN 10. A través del etiquetado 802.1q, esta VLAN puede transportarse a través de múltiples saltos de switch en la red del contribuidor, terminando en el switch que interfaza con el DZD remoto. -Esta solución se beneficia de ser ampliamente compatible y relativamente fácil de implementar, al tiempo que crea segmentación entre DoubleZero y los servicios de capa 3 internos. El ancho de banda puede controlarse según la velocidad de interfaz del switch o enrutador interno del contribuidor. Se debe prestar especial atención al rendimiento a través de la red L2 interna compartida mediante tecnologías como Calidad de Servicio (QoS) u otras políticas de gestión de tráfico. Sin embargo, las inversiones adicionales de CAPEX y OPEX deberían ser modestas si hay capacidad disponible dentro de la red troncal del contribuidor. +Esta solución se beneficia de ser ampliamente soportada y relativamente fácil de implementar, al tiempo que crea segmentación entre DoubleZero y los servicios internos de capa 3. El ancho de banda puede controlarse basándose en la velocidad de interfaz del switch o router interno del contribuidor. Se debe prestar cuidadosa consideración al rendimiento a través de la red L2 interna compartida mediante tecnologías como Calidad de Servicio (QoS) u otras políticas de gestión de tráfico. Sin embargo, las inversiones adicionales de CAPEX y OPEX deberían ser modestas si existe capacidad disponible dentro de la red core del contribuidor. #### Ancho de Banda Dedicado de Terceros
@@ -109,53 +111,53 @@ Esta solución se beneficia de ser ampliamente compatible y relativamente fácil
Figura 7: Ancho de Banda Dedicado de Terceros
-Si bien reutilizar la capacidad disponible será atractivo para muchos contribuidores de red, también se puede dedicar ancho de banda recién adquirido a DoubleZero. En tal escenario, el DZD se conectaría directamente al operador de terceros sin ningún dispositivo interno del contribuidor en línea (figura 7). +Si bien reutilizar capacidad disponible será atractivo para muchos contribuidores de red, también se puede dedicar ancho de banda recién adquirido a DoubleZero. En tal escenario, el DZD se conectaría directamente al operador de terceros sin que ningún dispositivo interno del contribuidor esté en línea (figura 7). -Esta opción es atractiva ya que garantiza ancho de banda dedicado para DoubleZero, es operativamente simple y asegura una segmentación completa de cualquier otro servicio de red. Esta opción probablemente tendrá el mayor aumento de OPEX y requiere nuevos contratos de servicio con operadores de terceros. +Esta opción es atractiva ya que garantiza ancho de banda dedicado para DoubleZero, es operativamente simple y asegura una segmentación completa de cualquier otro servicio de red. Esta opción probablemente tendrá el mayor incremento de OPEX y requiere nuevos contratos de servicio con operadores de terceros. --- ## Requisitos de Hardware -### Contribución de Ancho de Banda de 100 Gbps +### Contribución de Ancho de Banda de 100Gbps -Tenga en cuenta que las cantidades a continuación reflejan el equipo necesario en dos centros de datos, es decir, el hardware total necesario para desplegar 1 cable de fibra óptica para la contribución de ancho de banda. +Tenga en cuenta que las cantidades a continuación reflejan el equipo necesario en dos centros de datos, es decir, el hardware total requerido para desplegar 1 cable de fibra óptica para contribución de ancho de banda. -??? warning "*Todas las FPGAs están sujetas a pruebas finales. Las contribuciones de 10G pueden ser compatibles usando switches Arista 7130LBR con FPGAs Virtex® UltraScale+™ integradas duales (si tiene alguna pregunta, la Fundación DoubleZero / Malbec Labs están felices de proporcionar más información)." +??? warning "*Todas las FPGAs están sujetas a pruebas finales. Las contribuciones de 10G pueden ser soportadas usando switches Arista 7130LBR con FPGAs duales Virtex® UltraScale+™ integradas (si tiene alguna pregunta, DoubleZero Foundation / Malbec Labs estarán encantados de proporcionar más información)." -#### Requisitos de Función y Puerto +#### Requisitos de Función y Puertos -| Función | Velocidad de Puerto | Requisito DZ | CANT | Nota | +| Función | Velocidad del Puerto | Requisito DZ | CANT | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Ancho de Banda Privado | 100G | Sí | 1 | | -| Acceso Directo a Internet (DIA) | 10G | Sí | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sí* | 1 | Debe ser compatible cuando más de 3 proveedores operan en la misma área metropolitana; antes de esto, se pueden usar conexiones cruzadas u otros acuerdos de peering para interconectarse con otros proveedores. | -| Gestión | | No | 1 | Determinado por las propias políticas de gestión interna del contribuidor. | -| Consola | | No | 1 | Determinado por las propias políticas de gestión interna del contribuidor. | +| Ancho de Banda Privado | 100G | Sí | 1 | | +| Acceso Directo a Internet (DIA) | 10G | Sí | 2 | | +| DoubleZero eXchange (DZX) | 100G | Sí* | 1 | Debe soportarse una vez que más de 3 proveedores operen en la misma área metropolitana; antes de esto, se pueden usar cross-connects u otros acuerdos de peering para interconectarse con otros proveedores. | +| Gestión | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | +| Consola | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | #### Hardware de Red DZD -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474 | Sí | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son desafiantes. | +| AMD* | V80* | 24540474 | Sí | 4 | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son desafiantes. | --- -#### Óptica - 100G +#### Ópticas - 100G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | La elección de cableado y óptica está disponible a discreción del contribuidor. Se requieren 100G para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | El cableado y la elección de óptica quedan a discreción del contribuidor. Se requiere 100G para conectar FPGAs. | --- -#### Óptica - 10G +#### Ópticas - 10G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | No | 2 | La elección de cableado y óptica está disponible a discreción del contribuidor. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 2 | La elección de cableado y óptica está disponible a discreción del contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | No | 2 | El cableado y la elección de óptica quedan a discreción del contribuidor. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 2 | El cableado y la elección de óptica quedan a discreción del contribuidor. | --- @@ -163,70 +165,95 @@ Tenga en cuenta que las cantidades a continuación reflejan el equipo necesario | Direccionamiento IP | Tamaño Mínimo de Subred | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 Pública | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable a través de DIA. Podemos eliminar la necesidad de esto con el tiempo. | +| Public IPv4 | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable a través de DIA. Es posible que eliminemos esta necesidad con el tiempo. | -Asegúrese de que el pool /29 completo esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse mediante un pool de direcciones diferente. +Asegúrese de que el pool completo /29 esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse a través de un pool de direcciones diferente. -### Contribución de Ancho de Banda de 10 Gbps +### Contribución de Ancho de Banda de 10Gbps -Tenga en cuenta que las cantidades reflejan el equipo de dos centros de datos, es decir, el hardware total necesario para desplegar 1 contribución de ancho de banda. +Tenga en cuenta que las cantidades reflejan el equipo de dos centros de datos, es decir, el hardware total requerido para desplegar 1 contribución de ancho de banda. -#### Requisitos de Función y Puerto +#### Requisitos de Función y Puertos -| Función | Velocidad de Puerto | Requisito DZ | CANT | Nota | +| Función | Velocidad del Puerto | Requisito DZ | CANT | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Ancho de Banda Privado | 10G | Sí | 1 | | -| Acceso Directo a Internet (DIA) | 10G | Sí | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sí* | 1 | Debe ser compatible cuando más de 3 proveedores operan en la misma área metropolitana; antes de esto, se pueden usar conexiones cruzadas u otros acuerdos de peering para interconectarse con otros proveedores. | -| Gestión | | No | 1 | Determinado por las propias políticas de gestión interna del contribuidor. | -| Consola | | No | 1 | Determinado por las propias políticas de gestión interna del contribuidor. | +| Ancho de Banda Privado | 10G | Sí | 1 | | +| Acceso Directo a Internet (DIA) | 10G | Sí | 2 | | +| DoubleZero eXchange (DZX) | 100G | Sí* | 1 | Debe soportarse una vez que más de 3 proveedores operen en la misma área metropolitana; antes de esto, se pueden usar cross-connects u otros acuerdos de peering para interconectarse con otros proveedores. | +| Gestión | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | +| Consola | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | --- #### Hardware -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474* | Sí | 4 | | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son desafiantes. | +| AMD* | V80* | 24540474* | Sí | 4 | | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son desafiantes. | --- -#### Óptica - 100G +#### Ópticas - 100G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | La elección de cableado y óptica está disponible a discreción del contribuidor. Se requieren 100G para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | El cableado y la elección de óptica quedan a discreción del contribuidor. Se requiere 100G para conectar FPGAs. | --- -#### Óptica - 10G +#### Ópticas - 10G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | No | 4 | La elección de cableado y óptica está disponible a discreción del contribuidor. | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 4 | La elección de cableado y óptica está disponible a discreción del contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | No | 4 | El cableado y la elección de óptica quedan a discreción del contribuidor. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 4 | El cableado y la elección de óptica quedan a discreción del contribuidor. | --- #### Direccionamiento IP | Direccionamiento IP | Tamaño Mínimo de Subred | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 Pública | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable a través de DIA. Podemos eliminar la necesidad de esto con el tiempo. | +| Public IPv4 | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable a través de DIA. Es posible que eliminemos esta necesidad con el tiempo. | -Asegúrese de que el pool /29 completo esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse mediante un pool de direcciones diferente. +Asegúrese de que el pool completo /29 esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse a través de un pool de direcciones diferente. ### Requisitos del Centro de Datos #### Requisitos de Rack y Energía -| Requisito | Especificación | -|-------------|--------------| -| Espacio en Rack | 4U | -| Energía | 4KW (recomendado) | +Las cifras a continuación son **por DZD**, es decir, por centro de datos. Una contribución de ancho de banda de 100G o 10G coloca un DZD en cada extremo del enlace, así que planifique esto dos veces. + +##### Espacio en rack + +| Elemento | Unidades de rack | Necesario | +|------|-----------|--------| +| Switch DZD (Arista 7280CR3A-32S o 7130LBR) | 1U | Ahora | +| Dispositivo de filtrado en el borde | 1U | Más adelante, solo en dispositivos de borde e híbridos | + +**Reserve 2U por DZD.** Una unidad está en uso hoy. Mantenga la segunda libre para que el dispositivo de filtrado en el borde pueda instalarse junto al switch sin necesidad de mover el rack. Deje espacio para el flujo de aire y la gestión de cables según lo requiera su instalación. + +##### Energía + +| Elemento | Consumo típico | +|------|-------------| +| Arista 7280CR3A-32S | ~300 W | +| Ópticas, por QSFP 100G | ~5 W | + +**Solicite 2 kW por DZD, distribuidos en dos alimentaciones independientes.** Dimensione cada alimentación para soportar la carga completa por sí sola. El switch ejecuta fuentes de alimentación redundantes, y después de una falla de alimentación, una de ellas puede ser todo lo que le quede. + +2 kW es cómodo en lugar de ajustado. Un DZD solo con switch, que es lo que ejecuta casi todo despliegue hoy en día, consume bastante menos de 500 W con todas sus ópticas encendidas. El resto de los 2 kW está reservado para el dispositivo de filtrado en el borde, que contiene las FPGAs y se instala posteriormente. + +!!! warning "No solicite energía en exceso" + Usted paga por la energía que reserva, la consuma o no. Un DZD es una sola unidad de rack de conmutación, no un chasis de cómputo, por lo que consume mucho menos de lo que su posición en rack podría suministrar. Reservar más de 2 kW por DZD significa pagar por capacidad que permanece inactiva. + +!!! note "Verifique su propio hardware antes de realizar el pedido" + Estas son cifras orientativas de nuestros propios despliegues. Su consumo real depende de la configuración de su fuente de alimentación, cuántos puertos encienda y qué ópticas elija. Confirme contra las especificaciones de la fuente de alimentación en la hoja de datos del fabricante para el hardware exacto que compre. + + Tampoco reduzca el pedido al mínimo indispensable. La energía debe estar disponible en el rack, y agregar una alimentación más tarde generalmente implica un nuevo pedido con la instalación, lo cual puede tomar semanas. --- ## Próximos Pasos -¿Listo para aprovisionar su primer DZD? Continúe a la [Guía de Aprovisionamiento de Dispositivos](contribute-provisioning.md). +¿Listo para aprovisionar su primer DZD? Continúe con la [Guía de Aprovisionamiento de Dispositivos](contribute-provisioning.md). \ No newline at end of file diff --git a/docs/contribute.fr.md b/docs/contribute.fr.md index 49861fa..06dc331 100644 --- a/docs/contribute.fr.md +++ b/docs/contribute.fr.md @@ -1,232 +1,259 @@ -# Exigences et Architecture des Contributeurs -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Exigences et architecture en matière de matériel, de bande passante et de connectivité pour contribuer en capacité au réseau DoubleZero. +--- +# Exigences et architecture des contributeurs ## Résumé -Toute personne souhaitant monétiser ses câbles à fibre optique et son matériel réseau sous-utilisés peut contribuer au réseau DoubleZero. Les contributeurs réseau doivent fournir une bande passante dédiée entre deux points, exploiter des dispositifs compatibles DoubleZero (DZD) à chaque extrémité, et une connexion à l'internet public à chaque extrémité. Les contributeurs réseau doivent également exécuter des logiciels DoubleZero sur chaque DZD pour fournir des services comme le multicast, la recherche d'utilisateurs, et le filtrage en périphérie. +Toute personne souhaitant monétiser ses câbles à fibre optique et son matériel réseau sous-utilisés peut contribuer au réseau DoubleZero. Les contributeurs réseau doivent fournir une bande passante dédiée entre deux points, exploiter des appareils compatibles DoubleZero (DZD) à chaque extrémité, ainsi qu'une connexion à l'internet public à chaque extrémité. Les contributeurs réseau doivent également exécuter le logiciel DoubleZero sur chaque DZD pour fournir des services tels que le multicast, la recherche d'utilisateurs et le filtrage en périphérie. -Le contrat intelligent DoubleZero est la pierre angulaire pour garantir que le réseau maintient des liaisons de haute qualité qui peuvent être mesurées et intégrées dans la topologie, permettant à nos contrôleurs de réseau de développer le chemin le plus efficace de bout en bout entre nos différents utilisateurs et points d'extrémité. Lors de l'exécution du contrat intelligent et du déploiement du matériel réseau et de la bande passante, une entité est classifiée comme contributeur réseau. Voir [DoubleZero Economics](https://economics.doublezero.xyz/overview) pour mieux comprendre les aspects économiques de la participation à DoubleZero en tant que contributeur réseau. +Le contrat intelligent DoubleZero est la pierre angulaire garantissant que le réseau maintient des liens de haute qualité pouvant être mesurés et intégrés dans la topologie, permettant à nos contrôleurs réseau de développer le chemin de bout en bout le plus efficace entre nos différents utilisateurs et points de terminaison. Lors de l'exécution du contrat intelligent et du déploiement de l'équipement réseau et de la bande passante, une entité est classée comme contributeur réseau. Consultez [DoubleZero Economics](https://economics.doublezero.xyz/overview) pour mieux comprendre les aspects économiques de la participation à DoubleZero en tant que contributeur réseau. --- -## Exigences pour être un Contributeur Réseau DoubleZero +## Exigences pour devenir contributeur au réseau DoubleZero - Bande passante dédiée pouvant fournir une connectivité IPv4 et un MTU de 2048 octets entre deux centres de données - Matériel DoubleZero Device (DZD) compatible avec le protocole DoubleZero -- Connectivité à internet et aux autres contributeurs réseau DoubleZero +- Connectivité à Internet et aux autres contributeurs du réseau DoubleZero - Installation du logiciel DoubleZero sur le DZD -## Guide de Démarrage Rapide +## Guide de démarrage rapide -En tant que contributeur réseau, la façon la plus simple de commencer avec DoubleZero est d'identifier la capacité dans votre réseau qui peut être dédiée à DoubleZero. Une fois identifiés, des DZD doivent être déployés, facilitant le réseau superposé DoubleZero qui ne nécessite que la connectivité IPv4 et un MTU minimum de 2048 octets comme dépendances du réseau du contributeur. +En tant que contributeur réseau, la manière la plus simple de commencer avec DoubleZero est d'identifier la capacité de votre réseau pouvant être dédiée à DoubleZero. Une fois identifiée, les DZD doivent être déployés, facilitant le réseau overlay DoubleZero qui ne nécessite que l'accessibilité IPv4 et un MTU minimum de 2048 octets comme dépendances du réseau du contributeur. -La figure 1 met en évidence le modèle le plus simple pour contribuer des services de bande passante et d'envoi et de traitement de paquets. Un DZD est déployé dans chaque centre de données, s'interfaçant avec le réseau interne du contributeur réseau pour fournir une connectivité WAN DoubleZero. Cela est complété par un internet local, généralement une solution d'Accès Direct à Internet (DIA), qui est utilisé comme points d'entrée pour les utilisateurs DoubleZero. Bien qu'il soit prévu que DIA sera l'option préférée pour faciliter l'accès aux utilisateurs de DoubleZero, de nombreux modèles de connectivité sont possibles, par exemple le câblage physique vers des serveurs, l'extension de fabric réseau, etc. Nous appelons ces options Choose Your Own Adventure (CYOA), offrant au contributeur la flexibilité de connecter des utilisateurs locaux ou distants d'une manière qui convient le mieux à leurs politiques réseau internes. +La figure 1 illustre le modèle le plus simple pour la contribution en bande passante et les services d'envoi et de traitement de paquets. Un DZD est déployé dans chaque centre de données, s'interfaçant avec le réseau interne du contributeur réseau pour fournir la connectivité WAN DoubleZero. Cela est complété par un accès Internet local, généralement une solution d'accès Internet direct (DIA), utilisée comme points d'entrée pour les utilisateurs de DoubleZero. Bien que le DIA soit l'option privilégiée pour faciliter l'accès aux utilisateurs de DoubleZero, de nombreux modèles de connectivité sont possibles, par exemple : câblage physique vers les serveurs, extension de la fabric réseau, etc. Nous désignons ces options sous le nom de Choose Your Own Adventure (CYOA), offrant au contributeur la flexibilité de connecter des utilisateurs locaux ou distants de la manière la mieux adaptée à leurs politiques réseau internes. -Comme pour tout réseau, la connectivité est une partie fondamentale de l'architecture, car les contributeurs réseau ne peuvent pas vivre en isolement. En tant que tel, le DZD *doit* avoir un lien vers un DoubleZero Exchange (DZX) pour créer un réseau contigu entre les participants. +Comme pour tout réseau, l'accessibilité est une partie fondamentale de l'architecture, car les contributeurs réseau ne peuvent pas vivre de manière isolée. À ce titre, le DZD *doit* disposer d'un lien vers un DoubleZero Exchange (DZX) pour créer un réseau contigu entre les participants.
![Image title](images/figure1.png){ width="800" } -
Figure 1 : Contribution de Bande Passante Réseau DoubleZero Entre 2 Centres de Données - Contributeur Unique
+
Figure 1 : Contribution en bande passante au réseau DoubleZero entre 2 centres de données - Contributeur unique
-### Exemples de Contributions +### Exemples de contributions -Les façons dont un contributeur réseau peut développer ses contributions DoubleZero sont nombreuses, notamment : +Les moyens par lesquels un contributeur réseau peut accroître ses contributions à DoubleZero sont nombreux, notamment : -- Améliorer les caractéristiques de performance de leurs contributions existantes : augmenter la bande passante, réduire la latence +- Améliorer les caractéristiques de performance de ses contributions existantes : augmenter la bande passante, réduire la latence - Ajouter plusieurs liens entre les mêmes centres de données - Ajouter un nouveau lien d'un centre de données existant vers un nouveau centre de données - Ajouter un nouveau lien indépendant entre deux nouveaux centres de données -#### Exemple 1 : Contributeur Unique, 3 Centres de Données, Deux Liens +#### Exemple 1 : Contributeur unique, 3 centres de données, deux liens
![Image title](images/figure2.png){ width="800" } -
Figure 2 : Contribution de Bande Passante Réseau DoubleZero Entre 3 Centres de Données - Contributeur Unique
+
Figure 2 : Contribution en bande passante au réseau DoubleZero entre 3 centres de données - Contributeur unique
-Un seul DZD peut prendre en charge plusieurs liens contribués à DoubleZero. La figure 2 illustre une topologie potentielle si un seul centre de données, désigné comme 1, termine la bande passante vers deux centres de données distants différents 2 et 3. Dans ce scénario, chaque centre de données ne contient qu'un seul DZD. Tous les DZD utilisent DIA pour les points d'entrée des utilisateurs comme interface CYOA. +Un seul DZD peut prendre en charge plusieurs liens contribués à DoubleZero. La figure 2 illustre une topologie potentielle si un seul centre de données, désigné comme 1, termine la bande passante vers deux centres de données distants différents, 2 et 3. Dans ce scénario, chaque centre de données contient un seul DZD. Tous les DZD utilisent le DIA comme points d'entrée utilisateurs pour leur interface CYOA. -#### Exemple 2 : Contributeur Unique, 3 Centres de Données, Trois Liens +#### Exemple 2 : Contributeur unique, 3 centres de données, trois liens -La figure 3 décrit la topologie DoubleZero lorsqu'un seul contributeur déploie trois liens dans une topologie en triangle entre 3 centres de données. Dans un scénario similaire à l'exemple 1, un seul DZD est déployé dans les centres de données 1, 2 et 3, chacun prenant en charge 2 liens réseau indépendants. La topologie résultante est un triangle ou anneau entre les centres de données. +La figure 3 décrit la topologie DoubleZero lorsqu'un contributeur unique déploie trois liens dans une topologie en triangle entre 3 centres de données. Dans un scénario similaire à l'exemple 1, un seul DZD est déployé dans les centres de données 1, 2 et 3, chacun supportant 2 liens réseau indépendants. La topologie résultante est un triangle ou un anneau entre les centres de données.
![Image title](images/figure3.png){ width="800" } -
Figure 3 : Contribution de Bande Passante Réseau DoubleZero Entre 3 Centres de Données - Contributeur Unique
+
Figure 3 : Contribution en bande passante au réseau DoubleZero entre 3 centres de données - Contributeur unique
### DoubleZero Exchange -La création d'un réseau contigu est un élément fondamental de l'architecture DoubleZero. Les contributeurs s'interfacent via un DoubleZero Exchange (DZX) dans une zone métropolitaine, qui est une ville comme New York (NYC), Londres (LON) ou Tokyo (TYO). Un DZX est une fabric réseau similaire à un Internet Exchange, permettant le peering et l'échange de routes. +La création d'un réseau contigu est un élément fondamental de l'architecture DoubleZero. Les contributeurs s'interfacent via un DoubleZero Exchange (DZX) au sein d'une zone métropolitaine, c'est-à-dire une ville telle que New York (NYC), Londres (LON) ou Tokyo (TYO). Un DZX est une fabric réseau similaire à un point d'échange Internet, permettant le peering et l'échange de routes. Dans la figure 4, le contributeur réseau 1 opère dans les centres de données 1, 2 et 3, tandis que le contributeur réseau 2 opère dans les centres de données 2, 4 et 5. En s'interconnectant dans le centre de données 2, la portée du réseau DoubleZero s'étend à 5 centres de données contigus.
![Image title](images/figure4.png){ width="1000" } -
Figure 4 : Contribution de Bande Passante Réseau DoubleZero Entre 2 Contributeurs de Bande Passante Réseau
+
Figure 4 : Contribution en bande passante au réseau DoubleZero entre 2 contributeurs en bande passante réseau
-### Options de Contribution de Bande Passante +### Options de contribution en bande passante -DoubleZero exige qu'un contributeur réseau offre une connectivité intégrée via une bande passante garantie, un profil de latence et de gigue entre les DZD de deux centres de données de terminaison, exprimé via un contrat intelligent. DoubleZero ne mandate pas la façon dont un contributeur réseau met en œuvre sa contribution ; cependant, dans les sections suivantes, nous fournissons des options indicatives à leur usage à leur seule discrétion. +DoubleZero exige qu'un contributeur réseau offre une connectivité intégrée via un profil garanti de bande passante, de latence et de gigue entre les DZD de deux centres de données de terminaison, exprimé via un contrat intelligent. DoubleZero ne prescrit pas la manière dont un contributeur réseau met en œuvre sa contribution ; cependant, dans les sections suivantes, nous fournissons des options indicatives à utiliser à leur seule discrétion. -Les domaines importants à considérer pour un contributeur réseau pourraient être : +Les domaines importants à considérer pour un contributeur réseau peuvent être : - Capacité à garantir les performances réseau du service DoubleZero : bande passante, latence et gigue -- Ségrégation de leurs services réseau internes existants -- Conflits d'adressage IPv4, en particulier avec l'espace d'adresses du tunnel underlay -- Temps de disponibilité et disponibilité +- Séparation de leurs services réseau internes existants +- Conflits d'adressage IPv4, en particulier avec l'espace d'adressage de l'underlay tunnel +- Disponibilité et temps de fonctionnement - Considérations CAPEX et OPEX -#### Bande Passante de Couche 1 +#### Bande passante de couche 1
![Image title](images/figure5.png){ width="800" } -
Figure 5 : Services Optiques de Couche 1
+
Figure 5 : Services optiques de couche 1
-La bande passante de couche 1, plus formellement décrite comme services de longueur d'onde, peut voir une capacité dédiée provisionnée sur une infrastructure optique existante, telle que DWDM, CWDM ou via des multiplexeurs optiques (MUX). Dans la figure 5, les DZD utilisent une optique colorée câblée à un MUX L1, qui entrelace la longueur d'onde du DZD sur une fibre noire existante. +La bande passante de couche 1, plus formellement décrite comme des services de longueur d'onde, peut voir une capacité dédiée provisionnée sur une infrastructure optique existante, telle que DWDM, CWDM ou via des multiplexeurs optiques (MUX). Dans la figure 5, les DZD utilisent une optique colorée qui est câblée à un MUX L1, lequel entrelace la longueur d'onde du DZD sur une fibre noire existante. -Cette solution présente de nombreux avantages pour les contributeurs réseau qui exploitent déjà un réseau cœur existant. Les changements opérationnels itératifs, ainsi que les exigences supplémentaires en CAPEX et OPEX, sont modestes. Cette option est particulièrement robuste pour offrir la ségrégation des services réseau du contributeur. +Cette solution présente de nombreux avantages pour les contributeurs réseau qui exploitent déjà un réseau cœur existant. Les changements opérationnels itératifs, ainsi que les exigences supplémentaires en CAPEX et OPEX, sont modestes. Cette option est particulièrement robuste pour offrir une séparation des services réseau du contributeur. -#### Bande Passante Commutée par Paquets +#### Bande passante à commutation de paquets -Les réseaux commutés par paquets peuvent être considérés comme un réseau d'entreprise typique, exécutant des protocoles de routage et de commutation standard prenant en charge des applications commerciales. Il existe de nombreuses technologies réseau qui permettent la connectivité, par exemple, les extensions de couche 2 (L2) utilisant des balises VLAN. +Les réseaux à commutation de paquets peuvent être considérés comme un réseau d'entreprise typique, exécutant des protocoles de routage et de commutation standard supportant des applications métier. De nombreuses technologies réseau permettent d'atteindre la connectivité, par exemple, les extensions de couche 2 (L2) utilisant des tags VLAN. ##### Extension L2
![Image title](images/figure6.png){ width="800" } -
Figure 6 : Réseaux Commutés par Paquets - Extension L2
+
Figure 6 : Réseaux à commutation de paquets - Extension L2
-Une extension L2 comme illustrée dans la Figure 6 peut être facilitée par le balisage VLAN. Le port d'un DZD peut être câblé au commutateur du réseau interne d'un contributeur, avec le port de commutation configuré en mode accès dans, par exemple, VLAN 10. Via le balisage 802.1q, ce VLAN peut être transporté sur plusieurs sauts de commutation sur le réseau du contributeur, se terminant au commutateur interfaçant avec le DZD distant. +Une extension L2, comme illustrée dans la figure 6, peut être facilitée par le marquage VLAN. Le port d'un DZD peut être câblé au commutateur réseau interne d'un contributeur, avec le port du commutateur configuré comme port d'accès dans, par exemple, le VLAN 10. Via le marquage 802.1q, ce VLAN peut être transporté sur plusieurs sauts de commutateurs sur le réseau du contributeur, se terminant au commutateur interfaçant avec le DZD distant. -Cette solution bénéficie d'un large support et d'une mise en œuvre relativement facile tout en créant une segmentation entre DoubleZero et les services de couche 3 internes. La bande passante peut être contrôlée en fonction de la vitesse d'interface du commutateur ou routeur interne du contributeur. Une attention particulière doit être accordée aux performances sur le réseau L2 interne partagé via des technologies telles que la Qualité de Service (QoS) ou d'autres politiques de gestion du trafic. Cependant, les investissements supplémentaires en CAPEX et OPEX devraient être modestes si la capacité existante est disponible dans le réseau cœur du contributeur. +Cette solution bénéficie d'une prise en charge large et d'une mise en œuvre relativement facile tout en créant une segmentation entre DoubleZero et les services internes de couche 3. La bande passante peut être contrôlée en fonction de la vitesse d'interface du commutateur ou du routeur interne du contributeur. Une attention particulière doit être portée aux performances sur le réseau L2 interne partagé à travers des technologies telles que la qualité de service (QoS) ou d'autres politiques de gestion du trafic. Cependant, les investissements supplémentaires en CAPEX et OPEX devraient être modestes si une capacité existante est disponible au sein du réseau cœur du contributeur. -#### Bande Passante Tierce Dédiée +#### Bande passante dédiée tierce
![Image title](images/figure7.png){ width="800" } -
Figure 7 : Bande Passante Tierce Dédiée
+
Figure 7 : Bande passante dédiée tierce
-Bien que la réutilisation de la capacité disponible soit attrayante pour de nombreux contributeurs réseau, on peut également dédier une bande passante nouvellement acquise à DoubleZero. Dans un tel scénario, le DZD se connecterait directement au transporteur tiers sans aucun dispositif interne du contributeur en ligne (figure 7). +Bien que la réutilisation de la capacité disponible soit attractive pour de nombreux contributeurs réseau, il est également possible de dédier de la bande passante nouvellement acquise à DoubleZero. Dans un tel scénario, le DZD se connecterait directement à l'opérateur tiers sans aucun appareil interne du contributeur en ligne (figure 7). -Cette option est attrayante car elle garantit une bande passante dédiée pour DoubleZero, est simple opérationnellement et assure une ségrégation complète de tout autre service réseau. Cette option aura probablement la plus forte augmentation d'OPEX et nécessite de nouveaux contrats de service avec des transporteurs tiers. +Cette option est attractive car elle assure une bande passante dédiée pour DoubleZero, est simple sur le plan opérationnel et garantit une segmentation complète par rapport à tout autre service réseau. Cette option entraînera probablement la plus forte augmentation d'OPEX et nécessite de nouveaux contrats de service avec des opérateurs tiers. --- -## Exigences Matérielles +## Exigences matérielles -### Contribution de Bande Passante 100Gbps +### Contribution en bande passante 100 Gbps -Notez que les quantités ci-dessous reflètent le matériel nécessaire dans deux centres de données, c'est-à-dire le matériel total nécessaire pour déployer 1 câble à fibre optique pour la contribution de bande passante. +Notez que les quantités ci-dessous reflètent l'équipement nécessaire dans deux centres de données, c'est-à-dire le matériel total requis pour déployer 1 câble à fibre optique pour la contribution en bande passante. -??? warning "*Tous les FPGA sont soumis à des tests finaux. Les contributions 10G peuvent être prises en charge à l'aide de commutateurs Arista 7130LBR avec FPGA Virtex® UltraScale+™ double intégré (si vous avez des questions, la DoubleZero Foundation / Malbec Labs sont heureux de fournir plus d'informations)." +??? warning "*Tous les FPGA sont soumis à des tests finaux. Les contributions 10G peuvent être prises en charge à l'aide de commutateurs Arista 7130LBR avec des FPGA Virtex® UltraScale+™ doubles intégrés (si vous avez des questions, DoubleZero Foundation / Malbec Labs se feront un plaisir de fournir plus d'informations).*" -#### Exigences de Fonction et de Port +#### Exigences de fonction et de ports -| Fonction | Vitesse de Port | Exigence DZ | QTY | Note | -|-----------------------------|-----------------|-------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Bande Passante Privée | 100G | Oui | 1 | | -| Accès Direct à Internet (DIA) | 10G | Oui | 2 | | -| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge une fois que plus de 3 fournisseurs opèrent dans la même zone métropolitaine, avant cela, des interconnexions croisées ou d'autres arrangements de peering peuvent être utilisés pour s'interconnecter avec d'autres fournisseurs. | -| Gestion | | Non | 1 | Déterminé par les politiques de gestion internes du contributeur. | -| Console | | Non | 1 | Déterminé par les politiques de gestion internes du contributeur. | +| Fonction | Vitesse du port | Exigence DZ | QTÉ | Note | +|-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Bande passante privée | 100G | Oui | 1 | | +| Accès Internet direct (DIA) | 10G | Oui | 2 | | +| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge dès que plus de 3 fournisseurs opèrent dans la même zone métropolitaine ; avant cela, des interconnexions directes ou d'autres arrangements de peering peuvent être utilisés pour se connecter à d'autres fournisseurs. | +| Gestion | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | +| Console | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | -#### Matériel Réseau DZD +#### Matériel réseau DZD -| Fabricant | Modèle | Numéro de Pièce | Exigence DZ | QTY | Note | -|-----------|-----------------|----------------------|-------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474 | Oui | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être possibles si les délais de livraison sont difficiles. | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +|----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| +| AMD* | V80* | 24540474 | Oui | 4 | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être possibles si les délais de livraison sont contraignants. | --- #### Optiques - 100G -| Fabricant | Modèle | Numéro de Pièce | Exigence DZ | QTY | Note | -|-----------|-------------|----------------|-------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 16 | Le choix du câblage et de l'optique est à la discrétion du contributeur. 100G requis pour connecter les FPGA. | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 16 | Le choix du câblage et des optiques est à la discrétion du contributeur. 100G requis pour connecter les FPGA. | --- #### Optiques - 10G -| Fabricant | Modèle | Numéro de Pièce | Exigence DZ | QTY | Note | -|-----------|-------------|----------------|-------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Non | 2 | Le choix du câblage et de l'optique est à la discrétion du contributeur. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 2 | Le choix du câblage et de l'optique est à la discrétion du contributeur. | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 10GBASE-LR | SFP-10G-LR | Non | 2 | Le choix du câblage et des optiques est à la discrétion du contributeur. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 2 | Le choix du câblage et des optiques est à la discrétion du contributeur. | --- #### Adressage IP -| Adressage IP | Taille de Sous-réseau Minimale | Exigence DZ | Note | -|--------------|-------------------------------|-------------|----------------------------------------------------------| -| IPv4 Public | /29 | Oui (pour DZD de périphérie/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | +| Adressage IP | Taille minimale du sous-réseau | Exigence DZ | Note | +|--------------|-------------------|----------------|----------------------------------------------------------| +| IPv4 publique | /29 | Oui (pour les DZD edge/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | -Veuillez vous assurer que le pool /29 complet est disponible pour le protocole DZ. Les exigences pour l'adressage point à point, par exemple sur les interfaces DIA, doivent être gérées via un pool d'adresses différent. +Veuillez vous assurer que l'ensemble du pool /29 est disponible pour le protocole DZ. Tout besoin d'adressage point-à-point, par exemple sur les interfaces DIA, doit être géré via un pool d'adresses différent. -### Contribution de Bande Passante 10Gbps +### Contribution en bande passante 10 Gbps -Notez que les quantités reflètent le matériel de deux centres de données, c'est-à-dire le matériel total nécessaire pour déployer 1 contribution de bande passante. +Notez que les quantités reflètent l'équipement pour deux centres de données, c'est-à-dire le matériel total requis pour déployer 1 contribution en bande passante. -#### Exigences de Fonction et de Port +#### Exigences de fonction et de ports -| Fonction | Vitesse de Port | Exigence DZ | QTY | Note | -|-----------------------------|-----------------|-------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Bande Passante Privée | 10G | Oui | 1 | | -| Accès Direct à Internet (DIA) | 10G | Oui | 2 | | -| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge une fois que plus de 3 fournisseurs opèrent dans la même zone métropolitaine ; avant cela, des interconnexions croisées ou d'autres arrangements de peering peuvent être utilisés pour s'interconnecter avec d'autres fournisseurs. | -| Gestion | | Non | 1 | Déterminé par les politiques de gestion internes du contributeur. | -| Console | | Non | 1 | Déterminé par les politiques de gestion internes du contributeur. | +| Fonction | Vitesse du port | Exigence DZ | QTÉ | Note | +|-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Bande passante privée | 10G | Oui | 1 | | +| Accès Internet direct (DIA) | 10G | Oui | 2 | | +| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge dès que plus de 3 fournisseurs opèrent dans la même zone métropolitaine ; avant cela, des interconnexions directes ou d'autres arrangements de peering peuvent être utilisés pour se connecter à d'autres fournisseurs. | +| Gestion | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | +| Console | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | --- #### Matériel -| Fabricant | Modèle | Numéro de Pièce | Exigence DZ | QTY | Note | -|-----------|-----------------|----------------------|-------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474* | Oui | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être possibles si les délais de livraison sont difficiles. | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +|----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| +| AMD* | V80* | 24540474* | Oui | 4 | | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être possibles si les délais de livraison sont contraignants. | --- #### Optiques - 100G -| Fabricant | Modèle | Numéro de Pièce | Exigence DZ | QTY | Note | -|-----------|-------------|----------------|-------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 14 | Le choix du câblage et de l'optique est à la discrétion du contributeur. 100G requis pour connecter les FPGA. | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 14 | Le choix du câblage et des optiques est à la discrétion du contributeur. 100G requis pour connecter les FPGA. | --- #### Optiques - 10G -| Fabricant | Modèle | Numéro de Pièce | Exigence DZ | QTY | Note | -|-----------|-------------|----------------|-------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Non | 4 | Le choix du câblage et de l'optique est à la discrétion du contributeur. | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 4 | Le choix du câblage et de l'optique est à la discrétion du contributeur. | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 10GBASE-LR | SFP-10G-LR | Non | 4 | Le choix du câblage et des optiques est à la discrétion du contributeur. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 4 | Le choix du câblage et des optiques est à la discrétion du contributeur. | --- #### Adressage IP -| Adressage IP | Taille de Sous-réseau Minimale | Exigence DZ | Note | -|--------------|-------------------------------|-------------|----------------------------------------------------------| -| IPv4 Public | /29 | Oui (pour DZD de périphérie/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | +| Adressage IP | Taille minimale du sous-réseau | Exigence DZ | Note | +|--------------|-------------------|----------------|----------------------------------------------------------| +| IPv4 publique | /29 | Oui (pour les DZD edge/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | + +Veuillez vous assurer que l'ensemble du pool /29 est disponible pour le protocole DZ. Tout besoin d'adressage point-à-point, par exemple sur les interfaces DIA, doit être géré via un pool d'adresses différent. + +### Exigences du centre de données + +#### Exigences d'espace rack et d'alimentation + +Les chiffres ci-dessous sont **par DZD**, donc par centre de données. Une contribution en bande passante 100G ou 10G place un DZD à chaque extrémité du lien, il faut donc prévoir cela deux fois. + +##### Espace rack + +| Élément | Unités de rack | Nécessaire | +|------|-----------|--------| +| Commutateur DZD (Arista 7280CR3A-32S ou 7130LBR) | 1U | Maintenant | +| Appliance de filtrage en périphérie | 1U | Plus tard, uniquement sur les appareils edge et hybrides | + +**Réservez 2U par DZD.** Une unité est utilisée aujourd'hui. Gardez la seconde libre afin que l'appliance de filtrage en périphérie puisse être installée à côté du commutateur sans déplacement de rack. Laissez de l'espace pour la circulation d'air et la gestion des câbles selon les exigences de votre installation. + +##### Alimentation + +| Élément | Consommation typique | +|------|-------------| +| Arista 7280CR3A-32S | ~300 W | +| Optiques, par QSFP 100G | ~5 W | + +**Commandez 2 kW par DZD, répartis sur deux alimentations indépendantes.** Dimensionnez chaque alimentation pour supporter la charge complète seule. Le commutateur dispose d'alimentations redondantes, et après une défaillance d'alimentation, l'une d'entre elles peut être tout ce qu'il vous reste. -Veuillez vous assurer que le pool /29 complet est disponible pour le protocole DZ. Les exigences pour l'adressage point à point, par exemple sur les interfaces DIA, doivent être gérées via un pool d'adresses différent. +2 kW est confortable plutôt que juste. Un DZD composé uniquement d'un commutateur, ce qui correspond à la quasi-totalité des déploiements aujourd'hui, consomme bien moins de 500 W avec toutes ses optiques allumées. Le reste des 2 kW est réservé pour l'appliance de filtrage en périphérie, qui contient les FPGA et sera installée ultérieurement. -### Exigences du Centre de Données +!!! warning "Ne commandez pas trop de puissance" + Vous payez pour la puissance que vous réservez, que vous la consommiez ou non. Un DZD est une seule unité de rack de commutation, pas un châssis de calcul, il consomme donc bien moins que ce que sa position dans le rack pourrait fournir. Réserver plus de 2 kW par DZD signifie payer pour une capacité inutilisée. -#### Exigences de Baie et d'Alimentation +!!! note "Vérifiez votre propre matériel avant de commander" + Ce sont des chiffres indicatifs issus de nos propres déploiements. Votre consommation réelle dépend de la configuration de votre alimentation, du nombre de ports que vous allumez et des optiques que vous choisissez. Confirmez avec les spécifications d'alimentation dans la fiche technique du fabricant pour le matériel exact que vous achetez. -| Exigence | Spécification | -|-------------|--------------| -| Espace Baie | 4U | -| Alimentation | 4KW (recommandé) | + Ne réduisez pas non plus la commande au strict minimum. L'alimentation doit être disponible dans le rack, et ajouter une alimentation ultérieurement nécessite généralement une nouvelle commande auprès de l'installation, ce qui peut prendre des semaines. --- -## Prochaines Étapes +## Prochaines étapes -Prêt à provisionner votre premier DZD ? Continuez avec le [Guide de Provisionnement des Dispositifs](contribute-provisioning.md). +Prêt à provisionner votre premier DZD ? Continuez vers le [Guide de provisionnement des appareils](contribute-provisioning.md). \ No newline at end of file diff --git a/docs/contribute.it.md b/docs/contribute.it.md index 889d6cf..fe929f4 100644 --- a/docs/contribute.it.md +++ b/docs/contribute.it.md @@ -1,233 +1,259 @@ -# Requisiti e Architettura per i Contributori -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Requisiti hardware, di banda e di connettività e architettura per contribuire capacità alla rete DoubleZero. +--- +# Requisiti e Architettura per i Contributori -## Sommario +## Riepilogo -Chiunque desideri monetizzare i propri cavi in fibra ottica e hardware di rete sottoutilizzati può contribuire alla rete DoubleZero. I contributori di rete devono fornire larghezza di banda dedicata tra due punti, operare dispositivi compatibili con DoubleZero (DZD) ad entrambe le estremità, e una connessione alla rete internet pubblica ad entrambe le estremità. I contributori di rete devono anche eseguire il software DoubleZero su ogni DZD per fornire servizi come multicast, ricerca utenti e filtraggio perimetrale. +Chiunque desideri monetizzare i propri cavi in fibra ottica e hardware di rete sottoutilizzati può contribuire alla rete DoubleZero. I contributori di rete devono fornire banda dedicata tra due punti, operare dispositivi compatibili con DoubleZero (DZD) a ciascuna estremità e una connessione alla rete internet pubblica a ciascuna estremità. I contributori di rete devono inoltre eseguire il software DoubleZero su ciascun DZD per fornire servizi come multicast, ricerca utenti e filtraggio perimetrale. -Lo smart contract DoubleZero è il pilastro fondamentale per garantire che la rete mantenga link di alta qualità che possono essere misurati e integrati nella topologia, consentendo ai nostri controller di rete di sviluppare il percorso end-to-end più efficiente tra i diversi utenti e endpoint. A seguito dell'esecuzione dello smart contract e del deployment dell'infrastruttura di rete e della larghezza di banda, un'entità viene classificata come contributore di rete. Consulta [DoubleZero Economics](https://economics.doublezero.xyz/overview) per comprendere ulteriormente l'economia alla base della partecipazione a DoubleZero come contributore di rete. +Lo smart contract di DoubleZero è il pilastro fondamentale per garantire che la rete mantenga collegamenti di alta qualità che possano essere misurati e integrati nella topologia, consentendo ai nostri controller di rete di sviluppare il percorso end-to-end più efficiente tra i diversi utenti e endpoint. Al momento dell'esecuzione dello smart contract e del deployment delle apparecchiature di rete e della banda, un'entità viene classificata come contributore di rete. Consultare [DoubleZero Economics](https://economics.doublezero.xyz/overview) per comprendere meglio gli aspetti economici della partecipazione a DoubleZero come contributore di rete. --- -## Requisiti per Diventare un Contributore di Rete DoubleZero +## Requisiti per Diventare un Contributore della Rete DoubleZero -- Larghezza di banda dedicata in grado di fornire connettività IPv4 e un MTU di 2048 byte tra due data center +- Banda dedicata in grado di fornire connettività IPv4 e un MTU di 2048 byte tra due data center - Hardware DoubleZero Device (DZD) compatibile con il protocollo DoubleZero - Connettività a internet e ad altri contributori della rete DoubleZero - Installazione del software DoubleZero sul DZD -## Guida Rapida all'Avvio +## Guida Rapida Come contributore di rete, il modo più semplice per iniziare con DoubleZero è identificare la capacità nella propria rete che può essere dedicata a DoubleZero. Una volta identificata, i DZD devono essere distribuiti, facilitando la rete overlay DoubleZero che richiede solo raggiungibilità IPv4 e un MTU minimo di 2048 byte come dipendenze dalla rete del contributore. -La Figura 1 illustra il modello più semplice per contribuire con larghezza di banda e servizi di invio ed elaborazione dei pacchetti. Un DZD viene distribuito in ogni data center, interfacciandosi con la rete interna del contributore per fornire connettività WAN DoubleZero. Questo è integrato da un accesso internet locale, tipicamente una soluzione Direct Internet Access (DIA), utilizzata come punto di accesso per gli utenti DoubleZero. Mentre ci si aspetta che il DIA sia l'opzione preferita per facilitare l'accesso agli utenti di DoubleZero, sono possibili numerosi modelli di connettività, ad esempio cablaggio fisico ai server, estensione del fabric di rete, ecc. Ci riferiamo a queste opzioni come Choose Your Own Adventure (CYOA), fornendo al contributore la flessibilità di connettere utenti locali o remoti nel modo che meglio si adatta alle proprie politiche di rete interne. +La Figura 1 illustra il modello più semplice per contribuire banda e servizi di invio ed elaborazione dei pacchetti. Un DZD viene distribuito in ciascun data center, interfacciandosi con la rete interna del contributore per fornire connettività WAN DoubleZero. Questo è completato da internet locale, tipicamente una soluzione di Accesso Internet Diretto (DIA), utilizzata come punto di accesso per gli utenti DoubleZero. Sebbene si preveda che il DIA sarà l'opzione preferita per facilitare l'accesso agli utenti di DoubleZero, sono possibili numerosi modelli di connettività, ad esempio cablaggio fisico ai server, estensione del fabric di rete, ecc. Ci riferiamo a queste opzioni come Choose Your Own Adventure (CYOA), fornendo al contributore la flessibilità di connettere utenti locali o remoti nel modo più adatto alle proprie politiche di rete interna. -Come in qualsiasi rete, la raggiungibilità è una parte fondamentale dell'architettura poiché i contributori di rete non possono vivere in isolamento. Pertanto, il DZD *deve* avere un link a un DoubleZero Exchange (DZX) per creare una rete contigua tra i partecipanti. +Come per qualsiasi rete, la raggiungibilità è una parte fondamentale dell'architettura poiché i contributori di rete non possono operare in isolamento. Pertanto, il DZD *deve* avere un collegamento a un DoubleZero Exchange (DZX) per creare una rete contigua tra i partecipanti.
![Image title](images/figure1.png){ width="800" } -
Figura 1: Contributo di Larghezza di Banda alla Rete DoubleZero Tra 2 Data Center - Singolo Contributore
+
Figura 1: Contribuzione di Banda alla Rete DoubleZero tra 2 Data Center - Singolo Contributore
-### Esempi di Contributo +### Esempi di Contribuzione -I modi in cui un contributore di rete può ampliare i propri contributi a DoubleZero sono molteplici, tra cui: +I modi in cui un contributore di rete può ampliare le proprie contribuzioni a DoubleZero sono molteplici, tra cui: -- Migliorare le caratteristiche di prestazione dei contributi esistenti: aumentare la larghezza di banda, ridurre la latenza -- Aggiungere più link tra gli stessi data center -- Aggiungere un nuovo link da un data center esistente a un nuovo data center -- Aggiungere un nuovo link indipendente tra due nuovi data center +- Migliorare le caratteristiche prestazionali delle contribuzioni esistenti: aumentare la banda, ridurre la latenza +- Aggiungere più collegamenti tra gli stessi data center +- Aggiungere un nuovo collegamento da un data center esistente a un nuovo data center +- Aggiungere un nuovo collegamento indipendente tra due nuovi data center -#### Esempio 1: Singolo Contributore, 3 Data Center, Due Link +#### Esempio 1: Singolo Contributore, 3 Data Center, Due Collegamenti
![Image title](images/figure2.png){ width="800" } -
Figura 2: Contributo di Larghezza di Banda alla Rete DoubleZero Tra 3 Data Center - Singolo Contributore
+
Figura 2: Contribuzione di Banda alla Rete DoubleZero tra 3 Data Center - Singolo Contributore
-Un singolo DZD può supportare più link contribuiti a DoubleZero. La Figura 2 illustra una potenziale topologia se un singolo data center, indicato come 1, termina la larghezza di banda verso due diversi data center remoti 2 e 3. In questo scenario, ogni data center contiene solo 1 DZD. Tutti i DZD utilizzano il DIA per i punti di accesso degli utenti come interfaccia CYOA. +Un singolo DZD può supportare più collegamenti contribuiti a DoubleZero. La Figura 2 illustra una possibile topologia nel caso in cui un singolo data center, indicato come 1, termini la banda verso due diversi data center remoti 2 e 3. In questo scenario, ciascun data center contiene solo 1 DZD. Tutti i DZD utilizzano DIA per i punti di accesso utente come interfaccia CYOA. -#### Esempio 2: Singolo Contributore, 3 Data Center, Tre Link +#### Esempio 2: Singolo Contributore, 3 Data Center, Tre Collegamenti -La Figura 3 descrive la topologia DoubleZero quando un singolo contributore distribuisce tre link in una topologia a triangolo tra 3 data center. In uno scenario simile all'esempio 1, un singolo DZD viene distribuito nei data center 1, 2 e 3, ognuno dei quali supporta 2 link di rete indipendenti. La topologia risultante è un triangolo o anello tra i data center. +La Figura 3 descrive la topologia DoubleZero quando un singolo contributore distribuisce tre collegamenti in una topologia a triangolo tra 3 data center. In uno scenario simile all'esempio 1, un singolo DZD viene distribuito nei data center 1, 2 e 3, ciascuno con supporto per 2 collegamenti di rete indipendenti. La topologia risultante è un triangolo o anello tra i data center.
![Image title](images/figure3.png){ width="800" } -
Figura 3: Contributo di Larghezza di Banda alla Rete DoubleZero Tra 3 Data Center - Singolo Contributore
+
Figura 3: Contribuzione di Banda alla Rete DoubleZero tra 3 Data Center - Singolo Contributore
### DoubleZero Exchange -La creazione di una rete contigua è un elemento fondamentale dell'architettura DoubleZero. I contributori si interfacciano tramite un DoubleZero Exchange (DZX) all'interno di un'area metropolitana, ovvero una città come New York (NYC), Londra (LON) o Tokyo (TYO). Un DZX è un fabric di rete simile a un Internet Exchange, che consente il peering e lo scambio di route. +La creazione di una rete contigua è un elemento fondamentale dell'architettura DoubleZero. I contributori si interfacciano tramite un DoubleZero Exchange (DZX) all'interno di un'area metropolitana, ovvero una città come New York (NYC), Londra (LON) o Tokyo (TYO). Un DZX è un fabric di rete simile a un Internet Exchange, che consente il peering e lo scambio di rotte. -Nella Figura 4, il contributore di rete 1 opera nei data center 1, 2 e 3, mentre il contributore di rete 2 opera nei data center 2, 4 e 5. Interconnettendosi nel data center 2, la portata della rete DoubleZero si estende a 5 data center contigui. +Nella Figura 4, il contributore di rete 1 opera nei data center 1, 2 e 3, mentre il contributore di rete 2 opera nei data center 2, 4 e 5. Interconnettendosi nel data center 2, la copertura della rete DoubleZero aumenta a 5 data center contigui.
![Image title](images/figure4.png){ width="1000" } -
Figura 4: Contributo di Larghezza di Banda alla Rete DoubleZero Tra 2 Contributori di Larghezza di Banda
+
Figura 4: Contribuzione di Banda alla Rete DoubleZero tra 2 Contributori di Banda di Rete
-### Opzioni di Contributo della Larghezza di Banda +### Opzioni di Contribuzione della Banda -DoubleZero richiede a un contributore di rete di offrire connettività integrata tramite una larghezza di banda garantita, un profilo di latenza e jitter tra DZD in due data center di terminazione espresso tramite uno smart contract. DoubleZero non impone come un contributore di rete implementa il proprio contributo, tuttavia, nelle sezioni seguenti forniamo opzioni indicative per l'utilizzo a loro esclusiva discrezione. +DoubleZero richiede che un contributore di rete offra connettività integrata tramite un profilo garantito di banda, latenza e jitter tra i DZD in due data center terminali, espresso tramite uno smart contract. DoubleZero non impone come un contributore di rete implementi la propria contribuzione; tuttavia, nelle sezioni seguenti forniamo opzioni indicative da utilizzare a propria discrezione. Aree importanti da considerare per un contributore di rete potrebbero essere: -- Capacità di garantire le prestazioni di rete del servizio DoubleZero: larghezza di banda, latenza e jitter +- Capacità di garantire le prestazioni di rete del servizio DoubleZero: banda, latenza e jitter - Segregazione dai servizi di rete interni esistenti -- Conflitti di indirizzamento IPv4, in particolare con lo spazio di indirizzi underlay del tunnel +- Conflitti di indirizzamento IPv4, specificamente con lo spazio di indirizzi dell'underlay del tunnel - Uptime e disponibilità - Considerazioni su CAPEX e OPEX -#### Larghezza di Banda Layer 1 +#### Banda Layer 1
![Image title](images/figure5.png){ width="800" } -
Figura 5: Servizi Ottici Layer 1
+
Figura 5: Servizi Ottici Layer 1
-La larghezza di banda Layer 1, più formalmente descritta come servizi a lunghezza d'onda, può prevedere capacità dedicata su un'infrastruttura ottica esistente, come DWDM, CWDM o tramite multiplexer ottici (MUX). Nella Figura 5, i DZD utilizzano un'ottica colorata cablata a un MUX L1, che sovrappone la lunghezza d'onda del DZD su una fibra scura esistente. +La banda Layer 1, più formalmente descritta come servizi a lunghezza d'onda, può prevedere capacità dedicata fornita su un'infrastruttura ottica esistente, come DWDM, CWDM o tramite multiplexer ottici (MUX). Nella Figura 5, i DZD utilizzano un'ottica colorata collegata a un MUX L1, che inserisce la lunghezza d'onda del DZD su una fibra ottica spenta esistente. -Questa soluzione offre numerosi vantaggi per i contributori di rete che già gestiscono una rete core esistente. Le modifiche operative iterative, così come i requisiti aggiuntivi di CAPEX e OPEX, sono modesti. Questa opzione è particolarmente robusta nell'offrire segregazione dai servizi di rete del contributore. +Questa soluzione offre numerosi vantaggi per i contributori di rete che operano già una rete core esistente. Le modifiche operative incrementali, così come i requisiti aggiuntivi di CAPEX e OPEX, sono modesti. Questa opzione è particolarmente robusta nell'offrire segregazione dai servizi di rete del contributore. -#### Larghezza di Banda Packet Switched +#### Banda a Commutazione di Pacchetto -Le reti packet switched possono essere considerate una tipica rete aziendale, che esegue protocolli standard di routing e switching a supporto delle applicazioni aziendali. Esistono numerose tecnologie di rete che raggiungono la connettività, ad esempio estensioni layer 2 (L2) tramite tag VLAN. +Le reti a commutazione di pacchetto possono essere considerate una tipica rete aziendale, che esegue protocolli standard di routing e switching a supporto delle applicazioni aziendali. Esistono numerose tecnologie di rete che garantiscono la connettività, ad esempio estensioni layer 2 (L2) tramite tag VLAN. ##### Estensione L2
![Image title](images/figure6.png){ width="800" } -
Figura 6: Reti Packet Switched - Estensione L2
+
Figura 6: Reti a Commutazione di Pacchetto - Estensione L2
-Un'estensione L2 come mostrato nella Figura 6 può essere facilitata tramite il tagging VLAN. La porta di un DZD può essere cablata a uno switch della rete interna del contributore, con la porta dello switch impostata come porta di accesso, ad esempio, nella VLAN 10. Tramite il tagging 802.1q, questa VLAN può essere trasportata su più hop di switch sulla rete del contributore, terminando allo switch che si interfaccia con il DZD remoto. +Un'estensione L2 come mostrata nella Figura 6 può essere facilitata tramite il tagging VLAN. La porta di un DZD può essere collegata allo switch di rete interno del contributore, con la porta dello switch configurata come porta di accesso, ad esempio nella VLAN 10. Attraverso il tagging 802.1q, questa VLAN può essere trasportata su più hop di switch nella rete del contributore, terminando allo switch che si interfaccia con il DZD remoto. -Questa soluzione beneficia di un'ampia compatibilità e di una relativa facilità di implementazione, creando al contempo segmentazione tra DoubleZero e i servizi layer 3 interni. La larghezza di banda può essere controllata in base alla velocità dell'interfaccia dello switch o router interno del contributore. Occorre prestare particolare attenzione alle prestazioni attraverso la rete L2 interna condivisa tramite tecnologie come Quality of Service (QoS) o altre politiche di gestione del traffico. Tuttavia, gli investimenti aggiuntivi in CAPEX e OPEX dovrebbero essere modesti se è disponibile capacità esistente nella rete core del contributore. +Questa soluzione beneficia di un ampio supporto e di una relativa facilità di implementazione, creando al contempo segmentazione tra DoubleZero e i servizi layer 3 interni. La banda può essere controllata in base alla velocità dell'interfaccia dello switch o router interno del contributore. È necessario prestare particolare attenzione alle prestazioni sulla rete L2 interna condivisa attraverso tecnologie come Quality of Service (QoS) o altre politiche di gestione del traffico. Tuttavia, gli investimenti aggiuntivi in CAPEX e OPEX dovrebbero essere modesti se è disponibile capacità esistente all'interno della rete core del contributore. -#### Larghezza di Banda di Terze Parti Dedicata +#### Banda Dedicata di Terze Parti
![Image title](images/figure7.png){ width="800" } -
Figura 7: Larghezza di Banda di Terze Parti Dedicata
+
Figura 7: Banda Dedicata di Terze Parti
-Sebbene il riutilizzo della capacità disponibile sarà interessante per molti contributori di rete, è possibile anche dedicare larghezza di banda appena acquisita a DoubleZero. In tale scenario, il DZD si collegherebbe direttamente al gestore di terze parti senza alcun dispositivo interno del contributore in linea (Figura 7). +Sebbene il riutilizzo della capacità disponibile sarà attraente per molti contributori di rete, è anche possibile dedicare banda di nuova acquisizione a DoubleZero. In tale scenario, il DZD si collegherebbe direttamente al carrier di terze parti senza che alcun dispositivo interno del contributore si trovi in linea (Figura 7). -Questa opzione è interessante in quanto garantisce larghezza di banda dedicata per DoubleZero, è semplice dal punto di vista operativo e garantisce una completa segmentazione da qualsiasi altro servizio di rete. Questa opzione avrà probabilmente il maggiore aumento dell'OPEX e richiede nuovi contratti di servizio con gestori di terze parti. +Questa opzione è attraente in quanto garantisce banda dedicata per DoubleZero, è semplice dal punto di vista operativo e assicura una segmentazione completa da qualsiasi altro servizio di rete. Questa opzione comporterà probabilmente il maggiore incremento di OPEX e richiede nuovi contratti di servizio con carrier di terze parti. --- ## Requisiti Hardware -### Contributo di Larghezza di Banda 100Gbps +### Contribuzione di Banda a 100Gbps -Si noti che le quantità riportate di seguito riflettono l'attrezzatura necessaria in due data center, ovvero l'hardware totale necessario per distribuire 1 cavo in fibra ottica per il contributo di larghezza di banda. +Si noti che le quantità riportate di seguito riflettono l'attrezzatura necessaria in due data center, ovvero l'hardware totale richiesto per distribuire 1 cavo in fibra ottica per la contribuzione di banda. -??? warning "*Tutti gli FPGA sono soggetti a test finali. I contributi 10G possono essere supportati utilizzando switch Arista 7130LBR con FPGA dual Virtex® UltraScale+™ integrati (per qualsiasi domanda, DoubleZero Foundation / Malbec Labs sono lieti di fornire ulteriori informazioni)." +??? warning "*Tutti gli FPGA sono soggetti a test finali. Le contribuzioni a 10G possono essere supportate utilizzando switch Arista 7130LBR con doppi FPGA Virtex® UltraScale+™ integrati (per qualsiasi domanda, DoubleZero Foundation / Malbec Labs sono lieti di fornire ulteriori informazioni)." -#### Requisiti di Funzione e Porta +#### Requisiti di Funzione e Porte -| Funzione | Velocità Porta | Requisito DZ | QTY | Note | -|-----------------------------|---------------|--------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Larghezza di Banda Privata | 100G | Sì | 1 | | -| Direct Internet Access (DIA) | 10G | Sì | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato una volta che più di 3 provider operano nella stessa area metropolitana; prima di ciò, cross-connect o altri accordi di peering possono essere utilizzati per interconnettersi con altri provider. | -| Management | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | -| Console | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | +| Funzione | Velocità Porta | Requisito DZ | QTÀ | Nota | +|-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Private Bandwidth | 100G | Sì | 1 | | +| Direct Internet Access (DIA) | 10G | Sì | 2 | | +| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato quando più di 3 provider operano nella stessa area metropolitana; prima di ciò, è possibile utilizzare cross-connect o altri accordi di peering per interconnettersi ad altri provider. | +| Management | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | +| Console | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | #### Hardware di Rete DZD -| Produttore | Modello | Numero Parte | Requisito DZ | QTY | Note | -|------------|-----------------|----------------------|--------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474 | Sì | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Possono essere possibili alternative se i lead time sono problematici. | +| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +|----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| +| AMD* | V80* | 24540474 | Sì | 4 | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Potrebbero essere possibili alternative in caso di tempi di consegna difficili. | --- #### Ottiche - 100G -| Produttore | Modello | Numero Parte | Requisito DZ | QTY | Note | -|------------|-------------|----------------|--------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | Scelta di cablaggio e ottica a discrezione del contributore. 100G richiesto per connettere gli FPGA. | +| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | Cablaggio e scelta delle ottiche a discrezione del contributore. 100G richiesti per connettere gli FPGA. | --- #### Ottiche - 10G -| Produttore | Modello | Numero Parte | Requisito DZ | QTY | Note | -|------------|-------------|----------------|--------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | No | 2 | Scelta di cablaggio e ottica a discrezione del contributore. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 2 | Scelta di cablaggio e ottica a discrezione del contributore. | +| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 10GBASE-LR | SFP-10G-LR | No | 2 | Cablaggio e scelta delle ottiche a discrezione del contributore. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 2 | Cablaggio e scelta delle ottiche a discrezione del contributore. | --- #### Indirizzamento IP -| Indirizzamento IP | Dimensione Minima Sottorete | Requisito DZ | Note | -|------------------|---------------------------|--------------|----------------------------------------------------------| -| IPv4 Pubblico | /29 | Sì (per DZD edge/hybrid) | Deve essere instradabile tramite DIA. Potremmo eliminare la necessità di questo nel tempo. | +| Indirizzamento IP | Dimensione Minima Subnet | Requisito DZ | Nota | +|--------------|-------------------|----------------|----------------------------------------------------------| +| Public IPv4 | /29 | Sì (per DZD edge/ibridi) | Deve essere instradabile tramite DIA. Potremmo eliminare questa necessità nel tempo. | -Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Eventuali requisiti per l'indirizzamento point-to-point, ad esempio sulle interfacce DIA, devono essere gestiti tramite un pool di indirizzi diverso. +Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Eventuali requisiti di indirizzamento point-to-point, ad esempio sulle interfacce DIA, devono essere gestiti tramite un pool di indirizzi diverso. -### Contributo di Larghezza di Banda 10Gbps +### Contribuzione di Banda a 10Gbps -Si noti che le quantità riflettono l'attrezzatura di due data center, ovvero l'hardware totale necessario per distribuire 1 contributo di larghezza di banda. +Si noti che le quantità riflettono l'attrezzatura per due data center, ovvero l'hardware totale richiesto per distribuire 1 contribuzione di banda. -#### Requisiti di Funzione e Porta +#### Requisiti di Funzione e Porte -| Funzione | Velocità Porta | Requisito DZ | QTY | Note | -|-----------------------------|---------------|--------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Larghezza di Banda Privata | 10G | Sì | 1 | | -| Direct Internet Access (DIA) | 10G | Sì | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato una volta che più di 3 provider operano nella stessa area metropolitana; prima di ciò, cross-connect o altri accordi di peering possono essere utilizzati per interconnettersi con altri provider. | -| Management | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | -| Console | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | +| Funzione | Velocità Porta | Requisito DZ | QTÀ | Nota | +|-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Private Bandwidth | 10G | Sì | 1 | | +| Direct Internet Access (DIA) | 10G | Sì | 2 | | +| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato quando più di 3 provider operano nella stessa area metropolitana; prima di ciò, è possibile utilizzare cross-connect o altri accordi di peering per interconnettersi ad altri provider. | +| Management | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | +| Console | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | --- #### Hardware -| Produttore | Modello | Numero Parte | Requisito DZ | QTY | Note | -|------------|-----------------|----------------------|--------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474* | Sì | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Possono essere possibili alternative se i lead time sono problematici. | +| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +|----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| +| AMD* | V80* | 24540474* | Sì | 4 | | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Potrebbero essere possibili alternative in caso di tempi di consegna difficili. | --- #### Ottiche - 100G -| Produttore | Modello | Numero Parte | Requisito DZ | QTY | Note | -|------------|-------------|----------------|--------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | Scelta di cablaggio e ottica a discrezione del contributore. 100G richiesto per connettere gli FPGA. | +| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | Cablaggio e scelta delle ottiche a discrezione del contributore. 100G richiesti per connettere gli FPGA. | --- #### Ottiche - 10G -| Produttore | Modello | Numero Parte | Requisito DZ | QTY | Note | -|------------|-------------|----------------|--------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | No | 4 | Scelta di cablaggio e ottica a discrezione del contributore. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 4 | Scelta di cablaggio e ottica a discrezione del contributore. | - +| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +|--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| +| Arista | 10GBASE-LR | SFP-10G-LR | No | 4 | Cablaggio e scelta delle ottiche a discrezione del contributore. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 4 | Cablaggio e scelta delle ottiche a discrezione del contributore. | --- #### Indirizzamento IP -| Indirizzamento IP | Dimensione Minima Sottorete | Requisito DZ | Note | -|------------------|---------------------------|--------------|----------------------------------------------------------| -| IPv4 Pubblico | /29 | Sì (per DZD edge/hybrid) | Deve essere instradabile tramite DIA. Potremmo eliminare la necessità di questo nel tempo. | +| Indirizzamento IP | Dimensione Minima Subnet | Requisito DZ | Nota | +|--------------|-------------------|----------------|----------------------------------------------------------| +| Public IPv4 | /29 | Sì (per DZD edge/ibridi) | Deve essere instradabile tramite DIA. Potremmo eliminare questa necessità nel tempo. | -Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Eventuali requisiti per l'indirizzamento point-to-point, ad esempio sulle interfacce DIA, devono essere gestiti tramite un pool di indirizzi diverso. +Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Eventuali requisiti di indirizzamento point-to-point, ad esempio sulle interfacce DIA, devono essere gestiti tramite un pool di indirizzi diverso. ### Requisiti del Data Center #### Requisiti di Rack e Alimentazione -| Requisito | Specifica | -|-------------|-----------| -| Spazio Rack | 4U | -| Alimentazione | 4KW (raccomandato) | +Le cifre seguenti sono **per DZD**, quindi per data center. Una contribuzione di banda a 100G o 10G posiziona un DZD a ciascuna estremità del collegamento, quindi pianificare il tutto due volte. + +##### Spazio rack + +| Elemento | Unità rack | Necessario | +|------|-----------|--------| +| Switch DZD (Arista 7280CR3A-32S o 7130LBR) | 1U | Ora | +| Appliance di filtraggio perimetrale | 1U | In seguito, solo sui dispositivi edge e ibridi | + +**Riservare 2U per DZD.** Un'unità è in uso oggi. Mantenere la seconda libera in modo che l'appliance di filtraggio perimetrale possa essere posizionata accanto allo switch senza spostamenti nel rack. Lasciare spazio per il flusso d'aria e la gestione dei cavi come richiesto dalla propria struttura. + +##### Alimentazione + +| Elemento | Consumo tipico | +|------|-------------| +| Arista 7280CR3A-32S | ~300 W | +| Ottiche, per 100G QSFP | ~5 W | + +**Ordinare 2 kW per DZD, suddivisi su due alimentazioni indipendenti.** Dimensionare ciascuna alimentazione in modo da poter sostenere l'intero carico autonomamente. Lo switch dispone di alimentatori ridondanti e, dopo un guasto di una linea, uno di essi potrebbe essere l'unico rimasto. + +2 kW è una misura confortevole piuttosto che risicata. Un DZD con solo switch, che è ciò che esegue quasi ogni deployment oggi, consuma ben meno di 500 W con tutte le ottiche attive. Il resto dei 2 kW è riservato all'appliance di filtraggio perimetrale, che contiene gli FPGA e viene installata successivamente. + +!!! warning "Non sovradimensionare l'alimentazione" + Si paga per la potenza riservata, indipendentemente dal fatto che venga consumata o meno. Un DZD è una singola unità rack di switching, non un chassis di calcolo, quindi consuma molto meno di quanto la sua posizione nel rack potrebbe fornire. Riservare più di 2 kW per DZD significa pagare per capacità inutilizzata. + +!!! note "Verificare il proprio hardware prima di ordinare" + Queste sono cifre indicative dai nostri deployment. Il consumo reale dipende dalla configurazione degli alimentatori, dal numero di porte attivate e dalle ottiche scelte. Verificare rispetto alle specifiche degli alimentatori nel datasheet del produttore per l'hardware esatto acquistato. + + Non ridurre l'ordine al minimo indispensabile. L'alimentazione deve essere disponibile nel rack, e aggiungere una linea successivamente di solito comporta un nuovo ordine presso la struttura, che può richiedere settimane. --- ## Prossimi Passi -Pronto a effettuare il provisioning del tuo primo DZD? Continua con la [Guida al Provisioning dei Dispositivi](contribute-provisioning.md). +Pronti a effettuare il provisioning del vostro primo DZD? Proseguire alla [Guida al Provisioning del Dispositivo](contribute-provisioning.md). \ No newline at end of file diff --git a/docs/contribute.ja.md b/docs/contribute.ja.md index 3406210..058e5a8 100644 --- a/docs/contribute.ja.md +++ b/docs/contribute.ja.md @@ -1,233 +1,259 @@ -# コントリビューターの要件とアーキテクチャ -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: DoubleZeroネットワークへの容量提供に必要なハードウェア、帯域幅、接続要件およびアーキテクチャ。 +--- +# コントリビューター要件とアーキテクチャ ## 概要 -未活用の光ファイバーケーブルとネットワークハードウェアを収益化したい方はどなたでもDoubleZeroネットワークに貢献できます。ネットワークコントリビューターは、2点間に専用帯域幅を提供し、各端でDoubleZero互換デバイス（DZD）を運用し、各端でパブリックインターネットへの接続が必要です。ネットワークコントリビューターはまた、マルチキャスト、ユーザー検索、エッジフィルタリングなどのサービスを提供するために各DZDでDoubleZeroソフトウェアを実行する必要があります。 +未使用の光ファイバーケーブルやネットワークハードウェアを収益化したい方は、誰でもDoubleZeroネットワークに貢献することができます。ネットワークコントリビューターは、2つの拠点間で専用帯域幅を提供し、各端にDoubleZero対応デバイス（DZD）を運用し、各端でパブリックインターネットへの接続を確保する必要があります。また、ネットワークコントリビューターは、マルチキャスト、ユーザー検索、エッジフィルタリングなどのサービスを提供するために、各DZDでDoubleZeroソフトウェアを実行する必要があります。 -DoubleZeroスマートコントラクトは、ネットワークが測定可能でトポロジーに統合できる高品質のリンクを維持することを保証するための礎です。これにより、ネットワークコントローラーが異なるユーザーとエンドポイント間で最も効率的なエンドツーエンドパスを開発できます。スマートコントラクトの実行とネットワーク機器と帯域幅のデプロイメント後、エンティティはネットワークコントリビューターとして分類されます。DoubleZeroネットワークコントリビューターとしての参加背後の経済学をさらに理解するには、[DoubleZero Economics](https://economics.doublezero.xyz/overview)を参照してください。 +DoubleZeroスマートコントラクトは、ネットワークが高品質なリンクを維持し、それらを測定してトポロジに統合できることを保証するための基盤です。これにより、ネットワークコントローラーは異なるユーザーやエンドポイント間の最も効率的なエンドツーエンドパスを構築できます。スマートコントラクトの実行およびネットワーク機器と帯域幅の展開が完了すると、そのエンティティはネットワークコントリビューターとして分類されます。DoubleZeroにネットワークコントリビューターとして参加する際の経済的仕組みについては、[DoubleZero Economics](https://economics.doublezero.xyz/overview)をご覧ください。 --- -## DoubleZeroネットワークコントリビューターになる要件 +## DoubleZeroネットワークコントリビューターになるための要件 -- 2つのデータセンター間でIPv4接続とMTU 2048バイトを提供できる専用帯域幅 -- DoubleZeroプロトコルと互換性のあるDoubleZeroデバイス（DZD）ハードウェア -- インターネットおよびその他のDoubleZeroネットワークコントリビューターへの接続性 +- 2つのデータセンター間でIPv4接続と2048バイトのMTUを提供できる専用帯域幅 +- DoubleZeroプロトコルに対応したDoubleZero Device（DZD）ハードウェア +- インターネットおよび他のDoubleZeroネットワークコントリビューターへの接続性 - DZDへのDoubleZeroソフトウェアのインストール ## クイックスタートガイド -ネットワークコントリビューターとして、DoubleZeroを開始する最も簡単な方法は、DoubleZero専用に利用できる容量をネットワーク内で特定することです。特定したら、DZDをデプロイし、コントリビューターのネットワークからIPv4到達可能性と最低MTU 2048バイトのみを依存関係として必要とするDoubleZeroオーバーレイネットワークを促進する必要があります。 +ネットワークコントリビューターとして、DoubleZeroを始める最も簡単な方法は、DoubleZeroに専用で提供できるネットワーク内の空き容量を特定することです。特定後、DZDを展開する必要があります。DZDはDoubleZeroオーバーレイネットワークを構築し、コントリビューターのネットワークからの依存要件としてIPv4到達性と最小2048バイトのMTUのみを必要とします。 -図1は帯域幅とパケット送信・処理サービスを貢献するための最もシンプルなモデルを示しています。DZDは各データセンターに配備され、コントリビューターの内部ネットワークとインターフェースしてDoubleZero WAN接続を提供します。これはローカルインターネット（通常はDirect Internet Access（DIA）ソリューション）によって補完され、DoubleZeroユーザーのオンランプとして使用されます。DIAがDoubleZeroのユーザーアクセスを促進する優先オプションになることが予想されますが、物理ケーブリングからサーバーへ、ネットワークファブリック拡張など、さまざまな接続モデルが可能です。これらのオプションをChoose Your Own Adventure（CYOA）と呼び、コントリビューターが内部ネットワークポリシーに最も適した方法でローカルまたはリモートユーザーを接続する柔軟性を提供します。 +図1は、帯域幅の提供とパケット送受信・処理サービスの最もシンプルなモデルを示しています。各データセンターにDZDが展開され、ネットワークコントリビューターの内部ネットワークとインターフェースしてDoubleZero WAN接続を提供します。これに加えて、DoubleZeroユーザーのオンランプとして使用されるローカルインターネット（通常はDirect Internet Access（DIA）ソリューション）が補完的に提供されます。DIAがDoubleZeroユーザーへのアクセス提供の優先オプションとなることが予想されますが、サーバーへの物理ケーブリング、ネットワークファブリック拡張など、多数の接続モデルが可能です。これらのオプションをChoose Your Own Adventure（CYOA）と呼び、コントリビューターが内部ネットワークポリシーに最適な方法でローカルまたはリモートユーザーを接続する柔軟性を提供します。 -あらゆるネットワークと同様に、到達可能性はアーキテクチャの基本的な部分であり、ネットワークコントリビューターは孤立して存在できません。そのため、DZDは参加者間で連続したネットワークを作成するためにDoubleZero Exchange（DZX）へのリンクを**持たなければなりません**。 +あらゆるネットワークと同様に、到達性はアーキテクチャの基本的な要素であり、ネットワークコントリビューターは孤立して存在することはできません。そのため、DZDは参加者間の連続したネットワークを構築するために、DoubleZero Exchange（DZX）へのリンクを*必ず*持つ必要があります。
![Image title](images/figure1.png){ width="800" } -
図1：2つのデータセンター間のDoubleZeroネットワーク帯域幅貢献 - 単一コントリビューター
+
図1: 2つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
-### 貢献の例 +### 提供の例 -ネットワークコントリビューターがDoubleZeroへの貢献を拡大できる方法は多数あります。例えば： +ネットワークコントリビューターがDoubleZeroへの貢献を拡大する方法は多数あります。以下はその例です： -- 既存の貢献のパフォーマンス特性を改善する：帯域幅を増やし、レイテンシを減らす +- 既存の貢献のパフォーマンス特性を改善する：帯域幅の増加、レイテンシの削減 - 同じデータセンター間に複数のリンクを追加する - 既存のデータセンターから新しいデータセンターへの新しいリンクを追加する - 2つの新しいデータセンター間に新しい独立したリンクを追加する -#### 例1：単一コントリビューター、3データセンター、2リンク +#### 例1: 単一コントリビューター、3つのデータセンター、2つのリンク
![Image title](images/figure2.png){ width="800" } -
図2：3つのデータセンター間のDoubleZeroネットワーク帯域幅貢献 - 単一コントリビューター
+
図2: 3つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
-単一のDZDはDoubleZeroに提供される複数のリンクをサポートできます。図2は、データセンター1とそれぞれ異なるリモートデータセンター2と3の間の帯域幅を単一のデータセンターが終端する場合の潜在的なトポロジーを示しています。このシナリオでは、各データセンターには1つのDZDのみが含まれています。すべてのDZDはCYOAインターフェースとしてDIAをユーザーオンランプに使用しています。 +単一のDZDはDoubleZeroに提供される複数のリンクをサポートできます。図2は、データセンター1として示される単一のデータセンターが、2つの異なるリモートデータセンター2および3への帯域幅を終端する場合の潜在的なトポロジを示しています。このシナリオでは、各データセンターにDZDが1台のみ含まれます。すべてのDZDは、CYOAインターフェースとしてDIAをユーザーオンランプに使用しています。 -#### 例2：単一コントリビューター、3データセンター、3リンク +#### 例2: 単一コントリビューター、3つのデータセンター、3つのリンク -図3は単一のコントリビューターが3つのデータセンター間のトライアングルトポロジーに3つのリンクを展開した場合のDoubleZeroトポロジーを説明しています。例1に似たシナリオで、単一のDZDがデータセンター1、2、3に展開され、それぞれ2つの独立したネットワークリンクをサポートします。結果として得られるトポロジーはデータセンター間のトライアングルまたはリングです。 +図3は、単一のコントリビューターが3つのデータセンター間にトライアングルトポロジで3つのリンクを展開した場合のDoubleZeroトポロジを示しています。例1と同様のシナリオで、データセンター1、2、3にそれぞれ1台のDZDが展開され、各DZDが2つの独立したネットワークリンクをサポートします。結果として得られるトポロジは、データセンター間のトライアングルまたはリング型となります。
![Image title](images/figure3.png){ width="800" } -
図3：3つのデータセンター間のDoubleZeroネットワーク帯域幅貢献 - 単一コントリビューター
+
図3: 3つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
### DoubleZero Exchange -連続したネットワークの作成はDoubleZeroアーキテクチャの基本的な構成要素です。コントリビューターはニューヨーク（NYC）、ロンドン（LON）、東京（TYO）などの都市である大都市圏内のDoubleZero Exchange（DZX）を通じてインターフェースします。DZXはインターネットエクスチェンジに似たネットワークファブリックであり、ピアリングとルート交換を可能にします。 +連続したネットワークの構築は、DoubleZeroアーキテクチャの基本的な構成要素です。コントリビューターは、ニューヨーク（NYC）、ロンドン（LON）、東京（TYO）などの都市を単位とした大都市圏内のDoubleZero Exchange（DZX）を介してインターフェースします。DZXはインターネットエクスチェンジに類似したネットワークファブリックであり、ピアリングとルート交換を可能にします。 -図4では、ネットワークコントリビューター1はデータセンター1、2、3で運用し、ネットワークコントリビューター2はデータセンター2、4、5で運用しています。データセンター2で相互接続することで、DoubleZeroネットワークの到達範囲は5つの連続したデータセンターに拡大されます。 +図4では、ネットワークコントリビューター1がデータセンター1、2、3で運用し、ネットワークコントリビューター2がデータセンター2、4、5で運用しています。データセンター2で相互接続することにより、DoubleZeroネットワークのリーチが5つの連続したデータセンターに拡大されます。
![Image title](images/figure4.png){ width="1000" } -
図4：2つのネットワーク帯域幅コントリビューター間のDoubleZeroネットワーク帯域幅貢献
+
図4: 2つのネットワーク帯域幅コントリビューター間のDoubleZeroネットワーク帯域幅提供
-### 帯域幅貢献オプション +### 帯域幅提供オプション -DoubleZeroはネットワークコントリビューターに対し、スマートコントラクトを通じて表現される2つの終端データセンターのDZD間の保証された帯域幅、レイテンシ、ジッタープロファイルによる統合接続性を提供することを要求します。DoubleZeroはネットワークコントリビューターが貢献を実装する方法を義務付けていませんが、以下のセクションではそれぞれの判断で使用するための指示的オプションを提供します。 +DoubleZeroでは、ネットワークコントリビューターが2つの終端データセンターのDZD間で保証された帯域幅、レイテンシ、ジッタープロファイルを通じた統合接続をスマートコントラクトで提供する必要があります。DoubleZeroはネットワークコントリビューターが貢献をどのように実装するかを強制しませんが、以下のセクションではコントリビューターの裁量で使用できる参考オプションを提供します。 -ネットワークコントリビューターにとって考慮すべき重要な分野： +ネットワークコントリビューターが考慮すべき重要な領域： -- DoubleZeroサービスのネットワークパフォーマンスを保証する能力：帯域幅、レイテンシ、ジッター +- DoubleZeroサービスのネットワークパフォーマンス保証能力：帯域幅、レイテンシ、ジッター - 既存の内部ネットワークサービスからの分離 -- トンネルアンダーレイアドレス空間とのIPv4アドレッシングの衝突 +- IPv4アドレスの競合（特にトンネルアンダーレイアドレス空間との競合） - アップタイムと可用性 - CAPEXとOPEXの考慮事項 #### レイヤー1帯域幅
![Image title](images/figure5.png){ width="800" } -
図5：レイヤー1光学サービス
+
図5: レイヤー1光サービス
-レイヤー1帯域幅（より正式には波長サービスとも呼ばれる）は、DWDM、CWDMまたは光マルチプレクサー（MUX）などの既存の光学インフラに専用容量をプロビジョニングする場合があります。図5では、DZDはL1 MUXにケーブル接続されたカラードオプティクスを使用し、DZDの波長を既存のダークファイバーに多重化します。 +レイヤー1帯域幅（より正式には波長サービスと呼ばれる）は、DWDM、CWDMなどの既存の光インフラストラクチャ上、または光マルチプレクサ（MUX）を介して専用容量をプロビジョニングすることが可能です。図5では、DZDがカラードオプティックを使用し、L1 MUXにケーブル接続されており、既存のダークファイバー上にDZDの波長をインターリーブします。 -このソリューションには、既存のコアネットワークを運用しているネットワークコントリビューターにとって多くの利点があります。反復的な運用上の変更、および追加のCAPEXとOPEXの要件は控えめです。このオプションはネットワークコントリビューターのネットワークサービスからの分離を提供する上で特に堅牢です。 +このソリューションは、既存のコアネットワークを運用しているネットワークコントリビューターにとって多くの利点があります。段階的な運用変更、追加のCAPEXおよびOPEX要件は控えめです。このオプションは、ネットワークコントリビューターのネットワークサービスからの分離を提供する点で特に堅牢です。 -#### パケットスイッチド帯域幅 +#### パケットスイッチ帯域幅 -パケットスイッチドネットワークは、ビジネスアプリケーションをサポートする標準的なルーティングおよびスイッチングプロトコルを実行する典型的なエンタープライズネットワークと考えられます。VLANタグを使用したレイヤー2（L2）拡張など、接続を実現するさまざまなネットワーキング技術があります。 +パケットスイッチネットワークは、標準的なルーティングおよびスイッチングプロトコルを実行してビジネスアプリケーションをサポートする一般的なエンタープライズネットワークと見なすことができます。接続を実現するネットワーク技術は多数あり、例えばVLANタグを使用したレイヤー2（L2）拡張などがあります。 ##### L2拡張
![Image title](images/figure6.png){ width="800" } -
図6：パケットスイッチドネットワーク - L2拡張
+
図6: パケットスイッチネットワーク - L2拡張
-図6に示すL2拡張はVLANタギングを通じて実現できます。DZDのポートはコントリビューターの内部ネットワークスイッチにケーブル接続でき、スイッチポートは例えばVLAN 10のアクセスポートとして設定されます。802.1qタギングを通じて、このVLANはコントリビューターのネットワーク上の複数のスイッチホップを通じて運搬され、リモートDZDとインターフェースするスイッチで終端されます。 +図6に示すようなL2拡張は、VLANタグ付けによって実現できます。DZDのポートをコントリビューターの内部ネットワークスイッチにケーブル接続し、スイッチポートを例えばVLAN 10のアクセスポートとして設定します。802.1qタグ付けにより、このVLANはコントリビューターのネットワーク上の複数のスイッチホップを経由して転送され、リモートDZDとインターフェースするスイッチで終端されます。 -このソリューションは広くサポートされていて比較的実装が容易であり、DoubleZeroと内部レイヤー3サービス間のセグメンテーションを作成します。帯域幅はコントリビューターの内部スイッチまたはルーターのインターフェース速度に基づいて制御できます。Quality of Service（QoS）やその他のトラフィック管理ポリシーなどの技術を通じて、共有内部L2ネットワーク全体のパフォーマンスに慎重に考慮する必要があります。ただし、コントリビューターのコアネットワーク内に既存の容量がある場合、追加のCAPEXとOPEXの投資は控えめなはずです。 +このソリューションは、広くサポートされており比較的実装が容易であるという利点があり、DoubleZeroと内部レイヤー3サービス間のセグメンテーションを実現します。帯域幅は、コントリビューターの内部スイッチまたはルーターのインターフェース速度に基づいて制御できます。Quality of Service（QoS）やその他のトラフィック管理ポリシーなどの技術を通じて、共有内部L2ネットワーク全体のパフォーマンスに十分な注意を払う必要があります。ただし、コントリビューターのコアネットワーク内に既存の容量がある場合、追加のCAPEXおよびOPEX投資は控えめで済むはずです。 #### 専用サードパーティ帯域幅
![Image title](images/figure7.png){ width="800" } -
図7：専用サードパーティ帯域幅
+
図7: 専用サードパーティ帯域幅
-利用可能な容量を再利用することは多くのネットワークコントリビューターにとって魅力的ですが、新たに取得した帯域幅をDoubleZeroに専用することもできます。このようなシナリオでは、DZDはコントリビューターの内部デバイスをインラインに配置することなく、サードパーティキャリアに直接接続されます（図7）。 +利用可能な容量の再利用は多くのネットワークコントリビューターにとって魅力的ですが、新たに取得した帯域幅をDoubleZeroに専用で提供することも可能です。そのようなシナリオでは、DZDはコントリビューターの内部デバイスを経由せずに、サードパーティキャリアに直接接続します（図7）。 -このオプションはDoubleZero専用の帯域幅を確保し、運用がシンプルで、他のネットワークサービスからの完全な分離を確保するため魅力的です。このオプションはおそらく最も高いOPEXの増加をもたらし、サードパーティキャリアとの新しいサービス契約が必要です。 +このオプションは、DoubleZero専用の帯域幅を確保でき、運用がシンプルで、他のネットワークサービスからの完全な分離を保証するため魅力的です。このオプションはOPEXの増加が最も大きくなる可能性が高く、サードパーティキャリアとの新しいサービス契約が必要になります。 --- ## ハードウェア要件 -### 100Gbps帯域幅貢献 +### 100Gbps帯域幅提供 -以下の数量は2つのデータセンターで必要な機器、すなわち1本の光ファイバーケーブルの帯域幅貢献を展開するために必要な合計ハードウェアを反映しています。 +以下の数量は2つのデータセンターに必要な機器を反映しています。つまり、帯域幅提供用の光ファイバーケーブル1本を展開するために必要なハードウェアの合計です。 -??? warning "*すべてのFPGAは最終テスト次第です。10G貢献は組み込みデュアルVirtex® UltraScale+™ FPGAを持つArista 7130LBRスイッチを使用してサポートされる場合があります（ご質問があれば、DoubleZero Foundation / Malbec Labsが喜んで詳細情報を提供します）。" +??? warning "*すべてのFPGAは最終テストの対象です。10G提供は、デュアルVirtex® UltraScale+™ FPGAを内蔵したArista 7130LBRスイッチを使用してサポートされる場合があります（ご質問がある場合は、DoubleZero Foundation / Malbec Labsが詳細情報を提供いたします）。*" #### 機能とポート要件 -| 機能 | ポート速度 | DZ要件 | QTY | 注意 | +| 機能 | ポート速度 | DZ要件 | 数量 | 備考 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | プライベート帯域幅 | 100G | はい | 1 | | | Direct Internet Access (DIA) | 10G | はい | 2 | | -| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同じ大都市圏で3社以上のプロバイダーが運営する場合にサポートする必要があります。それ以前は、クロスコネクトまたは他のピアリング手配を使用して他のプロバイダーと相互接続できます。 | -| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーによって決定されます。 | -| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーによって決定されます。 | +| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同一メトロエリアで3つ以上のプロバイダーが運用を開始した時点でサポートが必要です。それ以前は、クロスコネクトまたはその他のピアリング契約を使用して他のプロバイダーと相互接続できます。 | +| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | +| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | #### DZDネットワークハードウェア -| メーカー | モデル | 部品番号 | DZ要件 | QTY | 注意 | +| メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | はい | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムが困難な場合は代替品も可能な場合があります。 | +| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムに問題がある場合、代替品が使用できる可能性があります。 | --- -#### 光学部品 - 100G +#### オプティクス - 100G -| メーカー | モデル | 部品番号 | DZ要件 | QTY | 注意 | +| メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 16 | ケーブリングと光学部品の選択はコントリビューターの裁量で利用可能です。FPGAの接続には100Gが必要です。 | +| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 16 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。FPGAの接続には100Gが必要です。 | --- -#### 光学部品 - 10G +#### オプティクス - 10G -| メーカー | モデル | 部品番号 | DZ要件 | QTY | 注意 | +| メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 2 | ケーブリングと光学部品の選択はコントリビューターの裁量で利用可能です。 | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 2 | ケーブリングと光学部品の選択はコントリビューターの裁量で利用可能です。 | +| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 2 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 2 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | --- -#### IPアドレッシング +#### IPアドレス -| IPアドレッシング | 最小サブネットサイズ | DZ要件 | 注意 | +| IPアドレス | 最小サブネットサイズ | DZ要件 | 備考 | |--------------|-------------------|----------------|----------------------------------------------------------| -| パブリックIPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にはこの必要性をなくす可能性があります。 | +| Public IPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にこの要件を廃止する可能性があります。 | -DZプロトコル用に完全な/29プールが利用可能であることを確認してください。DIAインターフェース上のポイントツーポイントアドレッシングなどの要件は、別のアドレスプールで管理する必要があります。 +DZプロトコル用に/29プール全体が利用可能であることを確認してください。ポイントツーポイントアドレッシングの要件（例：DIAインターフェース上）は、別のアドレスプールで管理してください。 -### 10Gbps帯域幅貢献 +### 10Gbps帯域幅提供 -以下の数量は2つのデータセンターの機器、すなわち1つの帯域幅貢献を展開するために必要な合計ハードウェアを反映しています。 +数量は2つのデータセンターの機器を反映しています。つまり、帯域幅提供1本を展開するために必要なハードウェアの合計です。 #### 機能とポート要件 -| 機能 | ポート速度 | DZ要件 | QTY | 注意 | +| 機能 | ポート速度 | DZ要件 | 数量 | 備考 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | プライベート帯域幅 | 10G | はい | 1 | | | Direct Internet Access (DIA) | 10G | はい | 2 | | -| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同じ大都市圏で3社以上のプロバイダーが運営する場合にサポートする必要があります。それ以前は、クロスコネクトまたは他のピアリング手配を使用して他のプロバイダーと相互接続できます。 | -| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーによって決定されます。 | -| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーによって決定されます。 | +| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同一メトロエリアで3つ以上のプロバイダーが運用を開始した時点でサポートが必要です。それ以前は、クロスコネクトまたはその他のピアリング契約を使用して他のプロバイダーと相互接続できます。 | +| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | +| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | --- #### ハードウェア -| メーカー | モデル | 部品番号 | DZ要件 | QTY | 注意 | +| メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474* | はい | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムが困難な場合は代替品も可能な場合があります。 | +| AMD* | V80* | 24540474* | はい | 4 | | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムに問題がある場合、代替品が使用できる可能性があります。 | --- -#### 光学部品 - 100G +#### オプティクス - 100G -| メーカー | モデル | 部品番号 | DZ要件 | QTY | 注意 | +| メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 14 | ケーブリングと光学部品の選択はコントリビューターの裁量で利用可能です。FPGAの接続には100Gが必要です。 | +| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 14 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。FPGAの接続には100Gが必要です。 | --- -#### 光学部品 - 10G +#### オプティクス - 10G -| メーカー | モデル | 部品番号 | DZ要件 | QTY | 注意 | +| メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 4 | ケーブリングと光学部品の選択はコントリビューターの裁量で利用可能です。 | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 4 | ケーブリングと光学部品の選択はコントリビューターの裁量で利用可能です。 | - +| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 4 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 4 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | --- -#### IPアドレッシング +#### IPアドレス -| IPアドレッシング | 最小サブネットサイズ | DZ要件 | 注意 | +| IPアドレス | 最小サブネットサイズ | DZ要件 | 備考 | |--------------|-------------------|----------------|----------------------------------------------------------| -| パブリックIPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にはこの必要性をなくす可能性があります。 | +| Public IPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にこの要件を廃止する可能性があります。 | -DZプロトコル用に完全な/29プールが利用可能であることを確認してください。DIAインターフェース上のポイントツーポイントアドレッシングなどの要件は、別のアドレスプールで管理する必要があります。 +DZプロトコル用に/29プール全体が利用可能であることを確認してください。ポイントツーポイントアドレッシングの要件（例：DIAインターフェース上）は、別のアドレスプールで管理してください。 ### データセンター要件 #### ラックと電力要件 -| 要件 | 仕様 | -|-------------|--------------| -| ラックスペース | 4U | -| 電力 | 4KW（推奨） | +以下の数値は**DZDごと**、つまりデータセンターごとの数値です。100Gまたは10G帯域幅提供では、リンクの各端にDZDを1台配置するため、これを2倍で計画してください。 + +##### ラックスペース + +| アイテム | ラックユニット | 必要時期 | +|------|-----------|--------| +| DZDスイッチ（Arista 7280CR3A-32S または 7130LBR） | 1U | 現在 | +| エッジフィルタリングアプライアンス | 1U | 後日、エッジおよびハイブリッドデバイスのみ | + +**DZDごとに2Uを確保してください。** 現在使用しているのは1ユニットです。エッジフィルタリングアプライアンスをラック移動なしでスイッチの隣に設置できるよう、2つ目を空けておいてください。施設の要件に応じて、エアフローとケーブル管理のためのスペースも確保してください。 + +##### 電力 + +| アイテム | 一般的な消費電力 | +|------|-------------| +| Arista 7280CR3A-32S | 約300 W | +| オプティクス（100G QSFPあたり） | 約5 W | + +**DZDごとに2 kWを発注し、2つの独立したフィードに分割してください。** 各フィードは単独で全負荷を支えられるようにサイジングしてください。スイッチは冗長電源を備えていますが、フィード障害後にはそのうち1つしか残らない可能性があります。 + +2 kWはギリギリではなく余裕のある数値です。現在ほぼすべてのデプロイメントで運用されているスイッチのみのDZDは、すべてのオプティクスを点灯しても500 W未満の消費です。残りの2 kWは、FPGAを搭載し後日設置されるエッジフィルタリングアプライアンス用に確保されています。 + +!!! warning "電力を過剰に発注しないでください" + 予約した電力は、実際に消費するかどうかに関わらず課金されます。DZDはスイッチング1ラックユニットであり、コンピュートシャーシではないため、ラック位置が供給可能な電力よりもはるかに少ない消費です。DZDごとに2 kWを超える予約は、使用されない容量に対して料金を支払うことを意味します。 + +!!! note "発注前に自身のハードウェアを確認してください" + これらは当社のデプロイメントに基づくガイドライン数値です。実際の消費電力は、電源構成、点灯するポート数、選択するオプティクスによって異なります。購入する正確なハードウェアのベンダーデータシートに記載されている電源定格で確認してください。 + + ただし、発注を最小限に削りすぎないでください。電力はラック内で利用可能である必要があり、後からフィードを追加するには通常施設への新規発注が必要となり、数週間かかることがあります。 --- ## 次のステップ -最初のDZDをプロビジョニングする準備ができましたか？[デバイスプロビジョニングガイド](contribute-provisioning.md)に進んでください。 +最初のDZDをプロビジョニングする準備はできましたか？[デバイスプロビジョニングガイド](contribute-provisioning.md)に進んでください。 \ No newline at end of file diff --git a/docs/contribute.ko.md b/docs/contribute.ko.md index 3e77281..44334e7 100644 --- a/docs/contribute.ko.md +++ b/docs/contribute.ko.md @@ -1,29 +1,31 @@ -# 기여자 요구사항 및 아키텍처 -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: DoubleZero 네트워크에 용량을 기여하기 위한 하드웨어, 대역폭, 연결 요구 사항 및 아키텍처. +--- +# 기여자 요구 사항 및 아키텍처 ## 요약 -미활용 광섬유 케이블과 네트워크 하드웨어를 수익화하고자 하는 누구든지 DoubleZero 네트워크에 기여할 수 있습니다. 네트워크 기여자는 두 지점 간에 전용 대역폭을 제공하고, 각 끝에 DoubleZero 호환 장치(DZD)를 운영하며, 각 끝에 공개 인터넷에 대한 연결이 있어야 합니다. 또한 네트워크 기여자는 각 DZD에서 멀티캐스트, 사용자 조회, 엣지 필터링과 같은 서비스를 제공하는 DoubleZero 소프트웨어를 실행해야 합니다. +사용률이 낮은 광섬유 케이블과 네트워크 하드웨어를 수익화하고자 하는 누구나 DoubleZero 네트워크에 기여할 수 있습니다. 네트워크 기여자는 두 지점 간 전용 대역폭을 제공하고, 각 끝단에서 DoubleZero 호환 장치(DZD)를 운영하며, 각 끝단에서 공용 인터넷 연결을 제공해야 합니다. 또한 네트워크 기여자는 멀티캐스트, 사용자 조회 및 엣지 필터링과 같은 서비스를 제공하기 위해 각 DZD에서 DoubleZero 소프트웨어를 실행해야 합니다. -DoubleZero 스마트 계약은 네트워크가 측정 가능하고 토폴로지에 통합될 수 있는 고품질 링크를 유지하도록 보장하는 핵심입니다. 이를 통해 네트워크 컨트롤러가 다양한 사용자와 엔드포인트 간의 가장 효율적인 엔드-투-엔드 경로를 개발할 수 있습니다. 스마트 계약 실행 및 네트워크 장비와 대역폭 배포 후에 해당 주체는 네트워크 기여자로 분류됩니다. DoubleZero 네트워크 기여자로서 참여하는 경제학을 더 잘 이해하려면 [DoubleZero 경제학](https://economics.doublezero.xyz/overview)을 참조하세요. +DoubleZero 스마트 컨트랙트는 네트워크가 측정되고 토폴로지에 통합될 수 있는 고품질 링크를 유지하도록 보장하는 핵심 요소로, 네트워크 컨트롤러가 다양한 사용자와 엔드포인트 간의 가장 효율적인 종단 간 경로를 개발할 수 있게 합니다. 스마트 컨트랙트가 실행되고 네트워크 장비 및 대역폭이 배포되면, 해당 엔티티는 네트워크 기여자로 분류됩니다. 네트워크 기여자로서 DoubleZero에 참여하는 것의 경제적 측면을 더 깊이 이해하려면 [DoubleZero Economics](https://economics.doublezero.xyz/overview)를 참조하십시오. --- -## DoubleZero 네트워크 기여자가 되기 위한 요구사항 +## DoubleZero 네트워크 기여자가 되기 위한 요구 사항 - 두 데이터 센터 간에 IPv4 연결 및 2048바이트 MTU를 제공할 수 있는 전용 대역폭 -- DoubleZero 프로토콜과 호환되는 DoubleZero 장치(DZD) 하드웨어 -- 인터넷 및 다른 DoubleZero 네트워크 기여자에 대한 연결 +- DoubleZero 프로토콜과 호환되는 DoubleZero Device(DZD) 하드웨어 +- 인터넷 및 다른 DoubleZero 네트워크 기여자와의 연결 - DZD에 DoubleZero 소프트웨어 설치 ## 빠른 시작 가이드 -네트워크 기여자로서 DoubleZero를 시작하는 가장 간단한 방법은 네트워크에서 DoubleZero에 전용으로 사용할 수 있는 용량을 파악하는 것입니다. 파악되면 DZD를 배포해야 하며, DZD는 기여자의 네트워크에서 의존성으로 IPv4 도달 가능성과 최소 2048바이트 MTU만 필요한 DoubleZero 오버레이 네트워크를 용이하게 합니다. +네트워크 기여자로서 DoubleZero를 시작하는 가장 간단한 방법은 DoubleZero에 전용으로 할당할 수 있는 네트워크 용량을 파악하는 것입니다. 용량이 파악되면, DZD를 배포하여 기여자의 네트워크에서 IPv4 도달 가능성과 최소 2048바이트의 MTU만을 의존하는 DoubleZero 오버레이 네트워크를 구성해야 합니다. -그림 1은 대역폭 및 패킷 전송과 처리 서비스를 기여하는 가장 간단한 모델을 강조합니다. DZD는 각 데이터 센터에 배포되어 기여자의 내부 네트워크와 인터페이스하여 DoubleZero WAN 연결을 제공합니다. 이는 DoubleZero 사용자를 위한 온-램프로 사용되는 로컬 인터넷(일반적으로 DIA(Direct Internet Access) 솔루션)으로 보완됩니다. DIA가 DoubleZero 사용자에게 액세스를 용이하게 하는 선호 옵션이 될 것으로 예상되지만, 다양한 연결 모델이 가능합니다(예: 서버에 대한 물리적 케이블링, 네트워크 패브릭 확장 등). 이 옵션을 CYOA(Choose Your Own Adventure)라고 하며, 기여자가 내부 네트워크 정책에 가장 잘 맞는 방식으로 로컬 또는 원격 사용자를 연결할 수 있는 유연성을 제공합니다. +그림 1은 대역폭 및 패킷 송수신·처리 서비스를 기여하는 가장 간단한 모델을 보여줍니다. 각 데이터 센터에 DZD가 배포되어 네트워크 기여자의 내부 네트워크와 인터페이스하며 DoubleZero WAN 연결을 제공합니다. 이는 DoubleZero 사용자를 위한 온램프로 사용되는 로컬 인터넷, 일반적으로 전용 인터넷 접속(DIA) 솔루션으로 보완됩니다. DIA가 DoubleZero 사용자에 대한 접근을 용이하게 하는 선호 옵션이 될 것으로 예상되지만, 서버에 대한 물리적 케이블링, 네트워크 패브릭 확장 등 다양한 연결 모델이 가능합니다. 이러한 옵션을 "자유 선택 방식(CYOA)"이라고 하며, 기여자가 내부 네트워크 정책에 가장 적합한 방식으로 로컬 또는 원격 사용자를 연결할 수 있는 유연성을 제공합니다. -모든 네트워크와 마찬가지로 도달 가능성은 아키텍처의 근본적인 부분입니다. 기여자들은 고립되어 있을 수 없기 때문입니다. 따라서 DZD는 참여자 간에 연속적인 네트워크를 만들기 위해 DoubleZero Exchange(DZX)에 링크가 있어야 합니다. +모든 네트워크와 마찬가지로, 네트워크 기여자가 고립되어 존재할 수 없으므로 도달 가능성은 아키텍처의 근본적인 부분입니다. 따라서 DZD는 참가자 간의 연속적인 네트워크를 생성하기 위해 DoubleZero Exchange(DZX)에 대한 링크를 *반드시* 가져야 합니다.
![Image title](images/figure1.png){ width="800" } @@ -32,12 +34,12 @@ DoubleZero 스마트 계약은 네트워크가 측정 가능하고 토폴로지 ### 기여 예시 -네트워크 기여자가 DoubleZero 기여를 확장할 수 있는 방법은 다음을 포함하여 다양합니다: +네트워크 기여자가 DoubleZero 기여를 확장할 수 있는 방법은 다양하며, 다음을 포함합니다: -- 기존 기여의 성능 특성 개선: 대역폭 증가, 대기 시간 감소 -- 동일한 데이터 센터 간에 여러 링크 추가 -- 기존 데이터 센터에서 새 데이터 센터로 새 링크 추가 -- 두 새 데이터 센터 간에 새로운 독립 링크 추가 +- 기존 기여의 성능 특성 향상: 대역폭 증가, 지연 시간 감소 +- 동일한 데이터 센터 간 다중 링크 추가 +- 기존 데이터 센터에서 새로운 데이터 센터로의 새 링크 추가 +- 두 개의 새로운 데이터 센터 간 독립적인 새 링크 추가 #### 예시 1: 단일 기여자, 3개 데이터 센터, 2개 링크
@@ -45,11 +47,11 @@ DoubleZero 스마트 계약은 네트워크가 측정 가능하고 토폴로지
그림 2: 3개 데이터 센터 간 DoubleZero 네트워크 대역폭 기여 - 단일 기여자
-단일 DZD는 DoubleZero에 기여하는 여러 링크를 지원할 수 있습니다. 그림 2는 1로 표시된 단일 데이터 센터가 두 개의 다른 원격 데이터 센터 2와 3에 대역폭을 종단하는 경우의 잠재적 토폴로지를 보여줍니다. 이 시나리오에서 각 데이터 센터에는 DZD가 하나만 있습니다. 모든 DZD는 CYOA 인터페이스로 DIA를 사용합니다. +단일 DZD는 DoubleZero에 기여된 다중 링크를 지원할 수 있습니다. 그림 2는 1로 표시된 단일 데이터 센터가 두 개의 서로 다른 원격 데이터 센터 2와 3으로의 대역폭을 종단하는 경우의 잠재적 토폴로지를 보여줍니다. 이 시나리오에서 각 데이터 센터에는 1개의 DZD만 포함됩니다. 모든 DZD는 CYOA 인터페이스로 사용자 온램프를 위해 DIA를 사용합니다. #### 예시 2: 단일 기여자, 3개 데이터 센터, 3개 링크 -그림 3은 단일 기여자가 3개 데이터 센터 사이에 삼각형 토폴로지로 3개 링크를 배포할 때의 DoubleZero 토폴로지를 설명합니다. 예시 1과 유사한 시나리오에서, 단일 DZD가 데이터 센터 1, 2, 3에 각각 배포되며 각각 2개의 독립 네트워크 링크를 지원합니다. 결과 토폴로지는 데이터 센터 간의 삼각형 또는 링입니다. +그림 3은 단일 기여자가 3개 데이터 센터 간에 삼각형 토폴로지로 3개 링크를 배포할 때의 DoubleZero 토폴로지를 설명합니다. 예시 1과 유사한 시나리오에서, 데이터 센터 1, 2, 3에 각각 단일 DZD가 배포되며 각각 2개의 독립적인 네트워크 링크를 지원합니다. 결과적인 토폴로지는 데이터 센터 간의 삼각형 또는 링 구조입니다.
![Image title](images/figure3.png){ width="800" } @@ -58,175 +60,189 @@ DoubleZero 스마트 계약은 네트워크가 측정 가능하고 토폴로지 ### DoubleZero Exchange -연속적인 네트워크 생성은 DoubleZero 아키텍처의 근본적인 구성 요소입니다. 기여자들은 뉴욕(NYC), 런던(LON) 또는 도쿄(TYO)와 같은 도시인 대도시권 내의 DoubleZero Exchange(DZX)를 통해 인터페이스하며, 이는 인터넷 익스체인지와 유사한 네트워크 패브릭으로 피어링 및 경로 교환을 허용합니다. +연속적인 네트워크의 생성은 DoubleZero 아키텍처의 근본적인 구성 요소입니다. 기여자는 뉴욕(NYC), 런던(LON) 또는 도쿄(TYO)와 같은 도시인 수도권 내의 DoubleZero Exchange(DZX)를 통해 인터페이스합니다. DZX는 인터넷 익스체인지와 유사한 네트워크 패브릭으로, 피어링과 라우트 교환을 가능하게 합니다. -그림 4에서 네트워크 기여자 1은 데이터 센터 1, 2, 3에서 운영하고, 네트워크 기여자 2는 데이터 센터 2, 4, 5에서 운영합니다. 데이터 센터 2에서 상호 연결함으로써 DoubleZero 네트워크 도달 범위가 5개의 연속 데이터 센터로 증가합니다. +그림 4에서 네트워크 기여자 1은 데이터 센터 1, 2, 3에서 운영하고, 네트워크 기여자 2는 데이터 센터 2, 4, 5에서 운영합니다. 데이터 센터 2에서 상호 연결함으로써 DoubleZero 네트워크 도달 범위가 5개의 연속적인 데이터 센터로 확장됩니다.
![Image title](images/figure4.png){ width="1000" } -
그림 4: 2개 네트워크 대역폭 기여자 간의 DoubleZero 네트워크 대역폭 기여
+
그림 4: 2개 네트워크 대역폭 기여자 간 DoubleZero 네트워크 대역폭 기여
### 대역폭 기여 옵션 -DoubleZero는 네트워크 기여자가 스마트 계약을 통해 두 종단 데이터 센터의 DZD 간에 보장된 대역폭, 대기 시간 및 지터 프로필을 통해 통합 연결을 제공하도록 요구합니다. DoubleZero는 네트워크 기여자가 기여를 구현하는 방법을 의무화하지 않지만, 다음 섹션에서는 단독 재량으로 사용할 수 있는 지시적 옵션을 제공합니다. +DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 종단 데이터 센터의 DZD 간 보장된 대역폭, 지연 시간 및 지터 프로파일을 통한 통합 연결을 제공할 것을 요구합니다. DoubleZero는 네트워크 기여자가 기여를 어떻게 구현하는지 규정하지 않지만, 다음 섹션에서 기여자의 독자적 판단에 따라 사용할 수 있는 참고 옵션을 제공합니다. 네트워크 기여자가 고려해야 할 중요한 영역은 다음과 같습니다: -- DoubleZero 서비스의 네트워크 성능 보장 능력: 대역폭, 대기 시간 및 지터 -- 기존 내부 네트워크 서비스로부터의 격리 -- 특히 터널 언더레이 주소 공간과의 IPv4 주소 충돌 +- DoubleZero 서비스의 네트워크 성능 보장 능력: 대역폭, 지연 시간, 지터 +- 기존 내부 네트워크 서비스로부터의 분리 +- IPv4 주소 충돌, 특히 터널 언더레이 주소 공간과의 충돌 - 가동 시간 및 가용성 - CAPEX 및 OPEX 고려 사항 -#### 계층 1 대역폭 +#### 레이어 1 대역폭
![Image title](images/figure5.png){ width="800" } -
그림 5: 계층 1 광학 서비스
+
그림 5: 레이어 1 광학 서비스
-보다 공식적으로 파장 서비스로 설명되는 계층 1 대역폭은 DWDM, CWDM 또는 광학 멀티플렉서(MUX)를 통해 기존 광학 인프라에 전용 용량을 프로비저닝할 수 있습니다. 그림 5에서 DZD는 L1 MUX에 케이블로 연결된 컬러 옵틱을 사용하며, 이는 DZD 파장을 기존 다크 파이버에 인터리빙합니다. +레이어 1 대역폭, 보다 공식적으로 파장 서비스라고 불리는 것은, DWDM, CWDM 또는 광 멀티플렉서(MUX)를 통해 기존 광학 인프라에 전용 용량을 프로비저닝하는 것입니다. 그림 5에서 DZD는 L1 MUX에 케이블링된 컬러 광학 모듈을 사용하며, 이는 DZD 파장을 기존 다크 파이버에 인터리빙합니다. -이 솔루션은 기존 핵심 네트워크를 이미 운영하는 네트워크 기여자에게 많은 이점을 제공합니다. 점진적인 운영 변경과 추가 CAPEX 및 OPEX 요구 사항은 적습니다. 이 옵션은 네트워크 기여자의 네트워크 서비스로부터 격리를 제공하는 데 특히 강력합니다. +이 솔루션은 이미 기존 코어 네트워크를 운영하고 있는 네트워크 기여자에게 많은 이점을 제공합니다. 반복적인 운영 변경과 추가 CAPEX 및 OPEX 요구 사항이 적당합니다. 이 옵션은 네트워크 기여자의 네트워크 서비스로부터의 분리를 제공하는 데 특히 강력합니다. -#### 패킷 교환 대역폭 +#### 패킷 스위칭 대역폭 -패킷 교환 네트워크는 비즈니스 애플리케이션을 지원하는 표준 라우팅 및 스위칭 프로토콜을 실행하는 일반적인 엔터프라이즈 네트워크로 간주될 수 있습니다. VLAN 태그를 사용한 계층 2(L2) 확장 등 다양한 네트워킹 기술을 통해 연결성을 달성할 수 있습니다. +패킷 스위칭 네트워크는 비즈니스 애플리케이션을 지원하는 표준 라우팅 및 스위칭 프로토콜을 실행하는 일반적인 엔터프라이즈 네트워크로 간주될 수 있습니다. VLAN 태그를 사용한 레이어 2(L2) 확장 등 연결을 달성하는 다양한 네트워킹 기술이 있습니다. ##### L2 확장
![Image title](images/figure6.png){ width="800" } -
그림 6: 패킷 교환 네트워크 - L2 확장
+
그림 6: 패킷 스위칭 네트워크 - L2 확장
-그림 6에 표시된 L2 확장은 VLAN 태깅을 통해 용이하게 할 수 있습니다. DZD의 포트는 기여자의 내부 네트워크 스위치에 케이블로 연결될 수 있으며, 스위치 포트는 예를 들어 VLAN 10의 액세스 포트로 설정됩니다. 802.1q 태깅을 통해 이 VLAN은 기여자의 네트워크에서 여러 스위치 홉을 통해 전달되어 원격 DZD와 인터페이스하는 스위치에서 종단됩니다. +그림 6에 표시된 L2 확장은 VLAN 태깅을 통해 구현할 수 있습니다. DZD의 포트를 기여자의 내부 네트워크 스위치에 케이블링하고, 스위치 포트를 예를 들어 VLAN 10의 액세스 포트로 설정할 수 있습니다. 802.1q 태깅을 통해 이 VLAN은 기여자의 네트워크에서 여러 스위치 홉을 거쳐 전달되어 원격 DZD와 인터페이스하는 스위치에서 종단됩니다. -이 솔루션은 널리 지원되고 구현하기 비교적 쉬우면서 DoubleZero와 내부 계층 3 서비스 간의 분리를 만드는 이점이 있습니다. 대역폭은 기여자의 내부 스위치 또는 라우터의 인터페이스 속도를 기반으로 제어할 수 있습니다. QoS(서비스 품질) 또는 기타 트래픽 관리 정책과 같은 기술을 통해 공유 내부 L2 네트워크의 성능에 신중한 고려가 필요합니다. 그러나 기여자의 핵심 네트워크 내에 기존 용량이 있는 경우 추가 CAPEX 및 OPEX 투자는 최소화되어야 합니다. +이 솔루션은 널리 지원되고 구현이 비교적 쉬우면서도 DoubleZero와 내부 레이어 3 서비스 간의 분리를 제공한다는 이점이 있습니다. 대역폭은 기여자 내부 스위치 또는 라우터의 인터페이스 속도에 따라 제어할 수 있습니다. QoS(Quality of Service) 또는 기타 트래픽 관리 정책과 같은 기술을 통해 공유 내부 L2 네트워크 전반의 성능을 신중하게 고려해야 합니다. 그러나 기여자의 코어 네트워크 내에 기존 용량이 있는 경우 추가 CAPEX 및 OPEX 투자는 적당할 것입니다. -#### 전용 3rd Party 대역폭 +#### 전용 제3자 대역폭
![Image title](images/figure7.png){ width="800" } -
그림 7: 전용 3rd Party 대역폭
+
그림 7: 전용 제3자 대역폭
-사용 가능한 용량을 재사용하는 것이 많은 네트워크 기여자에게 매력적이지만, 새로 획득한 대역폭을 DoubleZero에 전용으로 사용할 수도 있습니다. 이러한 시나리오에서 DZD는 인라인에 기여자의 내부 장치 없이 3rd party 통신사에 직접 연결됩니다(그림 7). +가용 용량을 재사용하는 것이 많은 네트워크 기여자에게 매력적이지만, 새로 확보한 대역폭을 DoubleZero에 전용으로 할당할 수도 있습니다. 이러한 시나리오에서 DZD는 기여자의 내부 장비 없이 제3자 통신사에 직접 연결됩니다(그림 7). -이 옵션은 DoubleZero를 위한 전용 대역폭을 보장하고 운영상 간단하며 다른 네트워크 서비스로부터 완전한 분리를 보장하기 때문에 매력적입니다. 이 옵션은 OPEX 증가가 가장 높고 3rd party 통신사와의 새로운 서비스 계약이 필요합니다. +이 옵션은 DoubleZero를 위한 전용 대역폭을 보장하고, 운영이 간단하며, 다른 네트워크 서비스로부터 완전한 분리를 보장한다는 점에서 매력적입니다. 이 옵션은 OPEX 증가가 가장 크고 제3자 통신사와의 새로운 서비스 계약이 필요할 가능성이 높습니다. --- -## 하드웨어 요구사항 +## 하드웨어 요구 사항 ### 100Gbps 대역폭 기여 -아래 수량은 두 데이터 센터에 필요한 장비를 반영합니다. 즉, 1개의 광섬유 케이블 대역폭 기여를 배포하는 데 필요한 총 하드웨어입니다. +아래 수량은 2개 데이터 센터에 필요한 장비를 반영합니다. 즉, 대역폭 기여를 위해 1개의 광섬유 케이블을 배포하는 데 필요한 총 하드웨어입니다. -??? warning "*모든 FPGA는 최종 테스트를 거칩니다. 10G 기여는 내장 이중 Virtex® UltraScale+™ FPGA가 있는 Arista 7130LBR 스위치를 사용하여 지원될 수 있습니다(질문이 있으면 DoubleZero Foundation / Malbec Labs가 기꺼이 더 많은 정보를 제공합니다)." +??? warning "*모든 FPGA는 최종 테스트를 거칩니다. 10G 기여는 내장 듀얼 Virtex® UltraScale+™ FPGA를 갖춘 Arista 7130LBR 스위치를 사용하여 지원될 수 있습니다(질문이 있으시면 DoubleZero Foundation / Malbec Labs가 기꺼이 추가 정보를 제공해 드립니다)." -#### 기능 및 포트 요구사항 +#### 기능 및 포트 요구 사항 -| 기능 | 포트 속도 | DZ 요구사항 | 수량 | 참고 | +| 기능 | 포트 속도 | DZ 요구 사항 | 수량 | 비고 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 전용 대역폭 | 100G | 예 | 1 | | -| DIA (Direct Internet Access) | 10G | 예 | 2 | | -| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일한 대도시권에 3개 이상의 공급자가 운영하면 반드시 지원해야 합니다. 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용할 수 있습니다. | -| 관리 | | 아니오 | 1 | 기여자의 내부 관리 정책에 따라 결정됩니다. | -| 콘솔 | | 아니오 | 1 | 기여자의 내부 관리 정책에 따라 결정됩니다. | +| Private Bandwidth | 100G | 예 | 1 | | +| Direct Internet Access (DIA) | 10G | 예 | 2 | | +| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일 수도권에서 3개 이상의 제공자가 운영되면 반드시 지원해야 합니다. 그 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용하여 다른 제공자와 상호 연결할 수 있습니다. | +| Management | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | +| Console | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | #### DZD 네트워크 하드웨어 -| 제조사 | 모델 | 부품 번호 | DZ 요구사항 | 수량 | 참고 | +| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474 | 예 | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | 예 | 2 | 리드 타임이 어려운 경우 대안이 가능할 수 있습니다. | +| AMD* | V80* | 24540474 | 예 | 4 | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | 예 | 2 | 리드 타임이 어려운 경우 대안이 가능할 수 있습니다. | --- -#### 광학 - 100G +#### 광학 모듈 - 100G -| 제조사 | 모델 | 부품 번호 | DZ 요구사항 | 수량 | 참고 | +| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 16 | 케이블링 및 광학 선택은 기여자의 재량에 따릅니다. FPGA를 연결하는 데 100G가 필요합니다. | +| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 16 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. FPGA 연결에 100G가 필요합니다. | --- -#### 광학 - 10G +#### 광학 모듈 - 10G -| 제조사 | 모델 | 부품 번호 | DZ 요구사항 | 수량 | 참고 | +| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 2 | 케이블링 및 광학 선택은 기여자의 재량에 따릅니다. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 2 | 케이블링 및 광학 선택은 기여자의 재량에 따릅니다. | +| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 2 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 2 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | --- #### IP 주소 지정 -| IP 주소 지정 | 최소 서브넷 크기 | DZ 요구사항 | 참고 | +| IP 주소 지정 | 최소 서브넷 크기 | DZ 요구 사항 | 비고 | |--------------|-------------------|----------------|----------------------------------------------------------| -| 공개 IPv4 | /29 | 예 (엣지/하이브리드 DZD의 경우) | DIA를 통해 라우팅 가능해야 합니다. 시간이 지남에 따라 이 요구사항을 없앨 수 있습니다. | +| Public IPv4 | /29 | 예 (엣지/하이브리드 DZD용) | DIA를 통해 라우팅 가능해야 합니다. 향후 이 요구 사항이 제거될 수 있습니다. | -DZ 프로토콜을 위해 전체 /29 풀이 사용 가능한지 확인하세요. DIA 인터페이스의 점대점 주소 지정 등의 요구 사항은 별도의 주소 풀을 통해 관리되어야 합니다. +전체 /29 풀이 DZ 프로토콜에 사용 가능한지 확인하십시오. 포인트 투 포인트 주소 지정 요구 사항(예: DIA 인터페이스)은 다른 주소 풀을 통해 관리해야 합니다. ### 10Gbps 대역폭 기여 -아래 수량은 두 데이터 센터의 장비를 반영합니다. 즉, 1개의 대역폭 기여를 배포하는 데 필요한 총 하드웨어입니다. +수량은 2개 데이터 센터의 장비를 반영합니다. 즉, 1개의 대역폭 기여를 배포하는 데 필요한 총 하드웨어입니다. -#### 기능 및 포트 요구사항 +#### 기능 및 포트 요구 사항 -| 기능 | 포트 속도 | DZ 요구사항 | 수량 | 참고 | +| 기능 | 포트 속도 | DZ 요구 사항 | 수량 | 비고 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 전용 대역폭 | 10G | 예 | 1 | | -| DIA (Direct Internet Access) | 10G | 예 | 2 | | -| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일한 대도시권에 3개 이상의 공급자가 운영하면 반드시 지원해야 합니다. 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용할 수 있습니다. | -| 관리 | | 아니오 | 1 | 기여자의 내부 관리 정책에 따라 결정됩니다. | -| 콘솔 | | 아니오 | 1 | 기여자의 내부 관리 정책에 따라 결정됩니다. | +| Private Bandwidth | 10G | 예 | 1 | | +| Direct Internet Access (DIA) | 10G | 예 | 2 | | +| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일 수도권에서 3개 이상의 제공자가 운영되면 반드시 지원해야 합니다. 그 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용하여 다른 제공자와 상호 연결할 수 있습니다. | +| Management | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | +| Console | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | --- #### 하드웨어 -| 제조사 | 모델 | 부품 번호 | DZ 요구사항 | 수량 | 참고 | +| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474* | 예 | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | 예 | 2 | 리드 타임이 어려운 경우 대안이 가능할 수 있습니다. | +| AMD* | V80* | 24540474* | 예 | 4 | | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | 예 | 2 | 리드 타임이 어려운 경우 대안이 가능할 수 있습니다. | --- -#### 광학 - 100G +#### 광학 모듈 - 100G -| 제조사 | 모델 | 부품 번호 | DZ 요구사항 | 수량 | 참고 | +| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 14 | 케이블링 및 광학 선택은 기여자의 재량에 따릅니다. FPGA를 연결하는 데 100G가 필요합니다. | +| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 14 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. FPGA 연결에 100G가 필요합니다. | --- -#### 광학 - 10G +#### 광학 모듈 - 10G -| 제조사 | 모델 | 부품 번호 | DZ 요구사항 | 수량 | 참고 | +| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 4 | 케이블링 및 광학 선택은 기여자의 재량에 따릅니다. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 4 | 케이블링 및 광학 선택은 기여자의 재량에 따릅니다. | +| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 4 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 4 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | --- #### IP 주소 지정 -| IP 주소 지정 | 최소 서브넷 크기 | DZ 요구사항 | 참고 | +| IP 주소 지정 | 최소 서브넷 크기 | DZ 요구 사항 | 비고 | |--------------|-------------------|----------------|----------------------------------------------------------| -| 공개 IPv4 | /29 | 예 (엣지/하이브리드 DZD의 경우) | DIA를 통해 라우팅 가능해야 합니다. 시간이 지남에 따라 이 요구사항을 없앨 수 있습니다. | +| Public IPv4 | /29 | 예 (엣지/하이브리드 DZD용) | DIA를 통해 라우팅 가능해야 합니다. 향후 이 요구 사항이 제거될 수 있습니다. | -DZ 프로토콜을 위해 전체 /29 풀이 사용 가능한지 확인하세요. DIA 인터페이스의 점대점 주소 지정 등의 요구 사항은 별도의 주소 풀을 통해 관리되어야 합니다. +전체 /29 풀이 DZ 프로토콜에 사용 가능한지 확인하십시오. 포인트 투 포인트 주소 지정 요구 사항(예: DIA 인터페이스)은 다른 주소 풀을 통해 관리해야 합니다. -### 데이터 센터 요구사항 +### 데이터 센터 요구 사항 -#### 랙 및 전원 요구사항 +#### 랙 및 전력 요구 사항 -| 요구사항 | 사양 | -|-------------|--------------| -| 랙 공간 | 4U | -| 전원 | 4KW (권장) | +아래 수치는 **DZD당**, 즉 데이터 센터당 기준입니다. 100G 또는 10G 대역폭 기여는 링크의 각 끝에 하나의 DZD를 배치하므로, 이를 두 번 계획하십시오. ---- +##### 랙 공간 + +| 항목 | 랙 유닛 | 필요 시점 | +|------|-----------|--------| +| DZD 스위치 (Arista 7280CR3A-32S 또는 7130LBR) | 1U | 현재 | +| 엣지 필터링 어플라이언스 | 1U | 추후, 엣지 및 하이브리드 장치에만 해당 | + +**DZD당 2U를 확보하십시오.** 현재 1유닛이 사용 중입니다. 엣지 필터링 어플라이언스를 랙 이동 없이 스위치 옆에 설치할 수 있도록 두 번째 유닛을 비워 두십시오. 시설 요구 사항에 따라 공기 흐름 및 케이블 관리를 위한 여유 공간을 남겨 두십시오. + +##### 전력 + +| 항목 | 일반적 소비 전력 | +|------|-------------| +| Arista 7280CR3A-32S | ~300 W | +| 광학 모듈, 100G QSFP당 | ~5 W | + +**DZD당 2 kW를 주문하고, 두 개의 독립적인 전원 피드에 분배하십시오.** 각 피드가 단독으로 전체 부하를 감당할 수 있도록 크기를 설정하십시오. 스위치는 이중화 전원 공급 장치를 운영하며, 피드 장애 후에는 하나만 남을 수 있습니다. -## 다음 단계 +2 kW는 빠듯하지 않고 여유 있는 수치입니다. 현재 거의 모든 배포에서 실행되는 스위치 전용 DZD는 모든 광학 모듈이 켜져 있어도 500 W 미만을 소비합니다. 나머지 2 kW는 FPGA를 포함하며 추후 설치되는 엣지 필터링 어플라이언스를 위해 예약되어 있습니다. -첫 번째 DZD를 프로비저닝할 준비가 되셨나요? [장치 프로비저닝 가이드](contribute-provisioning.md)를 계속하세요. +!!! warning "전력을 과도하게 주문하지 마십시오" + 사용 여부에 관계없이 예약한 전력에 대해 비용을 지불합니다. DZD는 컴퓨트 섀시가 아닌 단일 랙 유닛의 스위칭이므로, 랙 위치가 공급할 수 있는 것보다 훨씬 적은 전력을 소비합니다. DZD당 2 kW 이상을 예약하면 유 \ No newline at end of file diff --git a/docs/contribute.pt.md b/docs/contribute.pt.md index 0c6354a..71cfc76 100644 --- a/docs/contribute.pt.md +++ b/docs/contribute.pt.md @@ -1,29 +1,31 @@ -# Requisitos e Arquitetura para Contribuidores -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: Requisitos de hardware, largura de banda e conectividade, além da arquitetura para contribuir com capacidade para a rede DoubleZero. +--- +# Requisitos e Arquitetura para Contribuidores ## Resumo -Qualquer pessoa que deseje monetizar seus cabos de fibra ótica e hardware de rede subutilizados pode contribuir para a rede DoubleZero. Os contribuidores de rede devem fornecer largura de banda dedicada entre dois pontos, operar dispositivos compatíveis com DoubleZero (DZDs) em cada extremidade e ter conexão com a internet pública em cada extremidade. Os contribuidores de rede também devem executar software DoubleZero em cada DZD para fornecer serviços como multicast, pesquisa de usuários e filtragem de borda. +Qualquer pessoa que deseje monetizar seus cabos de fibra óptica e hardware de rede subutilizados pode contribuir para a rede DoubleZero. Os contribuidores de rede devem fornecer largura de banda dedicada entre dois pontos, operar dispositivos compatíveis com DoubleZero (DZDs) em cada extremidade e uma conexão à internet pública em cada extremidade. Os contribuidores de rede também devem executar o software DoubleZero em cada DZD para fornecer serviços como multicast, consulta de usuários e filtragem de borda. -O contrato inteligente DoubleZero é a pedra angular para garantir que a rede mantenha links de alta qualidade que possam ser medidos e integrados à topologia, permitindo que nossos controladores de rede desenvolvam o caminho mais eficiente de ponta a ponta entre nossos diferentes usuários e endpoints. Após a execução do contrato inteligente e a implantação do equipamento de rede e da largura de banda, uma entidade é classificada como contribuidor de rede. Consulte [Economia do DoubleZero](https://economics.doublezero.xyz/overview) para entender melhor a economia por trás da participação no DoubleZero como contribuidor de rede. +O smart contract DoubleZero é a pedra angular para garantir que a rede mantenha links de alta qualidade que possam ser medidos e integrados à topologia, permitindo que nossos controladores de rede desenvolvam o caminho fim-a-fim mais eficiente entre nossos diferentes usuários e endpoints. Após a execução do smart contract e a implantação dos equipamentos de rede e largura de banda, uma entidade é classificada como contribuidor de rede. Consulte [DoubleZero Economics](https://economics.doublezero.xyz/overview) para entender melhor a economia por trás da participação no DoubleZero como contribuidor de rede. --- ## Requisitos para ser um Contribuidor de Rede DoubleZero -- Largura de banda dedicada capaz de fornecer conectividade IPv4 e um MTU de 2048 bytes entre dois data centers -- Hardware de Dispositivo DoubleZero (DZD) compatível com o protocolo DoubleZero +- Largura de banda dedicada que possa fornecer conectividade IPv4 e um MTU de 2048 bytes entre dois data centers +- Hardware DoubleZero Device (DZD) compatível com o protocolo DoubleZero - Conectividade com a internet e outros contribuidores de rede DoubleZero - Instalação do software DoubleZero no DZD ## Guia de Início Rápido -Como contribuidor de rede, a maneira mais simples de começar no DoubleZero é identificar capacidade em sua rede que possa ser dedicada ao DoubleZero. Uma vez identificados, os DZDs devem ser implantados, facilitando a rede overlay DoubleZero que requer apenas alcançabilidade IPv4 e um MTU mínimo de 2048 bytes como dependências da rede do contribuidor. +Como contribuidor de rede, a maneira mais simples de começar no DoubleZero é identificando capacidade em sua rede que possa ser dedicada ao DoubleZero. Uma vez identificada, os DZDs devem ser implantados, facilitando a rede overlay DoubleZero que requer apenas alcançabilidade IPv4 e um MTU mínimo de 2048 bytes como suas dependências da rede do contribuidor. -A Figura 1 destaca o modelo mais simples para contribuição de largura de banda e serviços de envio e processamento de pacotes. Um DZD é implantado em cada data center, conectando-se à rede interna do contribuidor de rede para fornecer conectividade WAN DoubleZero. Isso é complementado pela internet local, tipicamente uma solução de Acesso Direto à Internet (DIA), que é usada como pontos de entrada para usuários DoubleZero. Embora se espere que o DIA seja a opção preferida para facilitar o acesso aos usuários do DoubleZero, vários modelos de conectividade são possíveis, como cabeamento físico para servidores, extensão de fabric de rede, etc. Nos referimos a essas opções como Choose Your Own Adventure (CYOA), fornecendo ao contribuidor flexibilidade para conectar usuários locais ou remotos de uma forma que melhor se adapte às suas políticas de rede internas. +A Figura 1 destaca o modelo mais simples para contribuição de largura de banda e serviços de envio e processamento de pacotes. Um DZD é implantado em cada data center, conectando-se à rede interna do contribuidor de rede para fornecer conectividade WAN DoubleZero. Isso é complementado por internet local, tipicamente uma solução de Acesso Direto à Internet (DIA), que é usada como pontos de acesso para os usuários DoubleZero. Embora se espere que o DIA seja a opção preferida para facilitar o acesso aos usuários do DoubleZero, diversos modelos de conectividade são possíveis, por exemplo, cabeamento físico para servidores, extensão de fabric de rede, etc. Nos referimos a essas opções como Choose Your Own Adventure (CYOA), proporcionando ao contribuidor flexibilidade para conectar usuários locais ou remotos da maneira que melhor se adeque às suas políticas internas de rede. -Como em qualquer rede, a alcançabilidade é uma parte fundamental da arquitetura, pois os contribuidores de rede não podem viver isolados. Como tal, o DZD *deve* ter um link para uma DoubleZero Exchange (DZX) para criar uma rede contígua entre os participantes. +Como em qualquer rede, a alcançabilidade é uma parte fundamental da arquitetura, pois os contribuidores de rede não podem operar isoladamente. Sendo assim, o DZD *deve* ter um link para um DoubleZero Exchange (DZX) para criar uma rede contígua entre os participantes.
![Image title](images/figure1.png){ width="800" } @@ -32,9 +34,9 @@ Como em qualquer rede, a alcançabilidade é uma parte fundamental da arquitetur ### Exemplos de Contribuições -As formas pelas quais um contribuidor de rede pode expandir suas contribuições DoubleZero são muitas, incluindo: +As formas pelas quais um contribuidor de rede pode expandir suas contribuições ao DoubleZero são muitas, incluindo: -- Melhorar as características de desempenho de suas contribuições existentes: aumentar largura de banda, reduzir latência +- Melhorar as características de desempenho de suas contribuições existentes: aumentar a largura de banda, reduzir a latência - Adicionar múltiplos links entre os mesmos data centers - Adicionar um novo link de um data center existente para um novo data center - Adicionar um novo link independente entre dois novos data centers @@ -45,73 +47,73 @@ As formas pelas quais um contribuidor de rede pode expandir suas contribuições
Figura 2: Contribuição de Largura de Banda da Rede DoubleZero Entre 3 Data Centers - Contribuidor Único
-Um único DZD pode suportar múltiplos links contribuídos ao DoubleZero. A Figura 2 ilustra uma topologia potencial se um único data center, denominado 1, terminar largura de banda para dois data centers remotos diferentes 2 e 3. Neste cenário, cada data center contém apenas 1 DZD. Todos os DZDs estão usando DIA para pontos de entrada de usuários como sua interface CYOA. +Um único DZD pode suportar múltiplos links contribuídos ao DoubleZero. A Figura 2 ilustra uma topologia potencial se um único data center, denominado 1, termina largura de banda para dois data centers remotos diferentes, 2 e 3. Neste cenário, cada data center contém apenas 1 DZD. Todos os DZDs estão usando DIA para pontos de acesso de usuários como sua interface CYOA. #### Exemplo 2: Contribuidor Único, 3 Data Centers, Três Links -A Figura 3 descreve a topologia DoubleZero quando um único contribuidor implanta três links em uma topologia triangular entre 3 data centers. Em um cenário semelhante ao exemplo 1, um único DZD é implantado nos data centers 1, 2 e 3, cada um suportando 2 links de rede independentes. A topologia resultante é um triângulo ou anel entre os data centers. +A Figura 3 descreve a topologia DoubleZero quando um único contribuidor implanta três links em uma topologia triangular entre 3 data centers. Em um cenário semelhante ao exemplo 1, um único DZD é implantado nos data centers 1, 2 e 3, cada um suportando 2 links de rede independentes. A topologia resultante é um triângulo ou anel entre data centers.
![Image title](images/figure3.png){ width="800" } -
Figura 3: Contribuição de Largura de Banda da Rede DoubleZero Entre 3 Data Centers - Contribuidor Único
+
Figura 3: Contribuição de Largura de Banda da Rede DoubleZero Entre 3 Data Centers - Contribuidor Único
### DoubleZero Exchange -A criação de uma rede contígua é um bloco fundamental da arquitetura DoubleZero. Os contribuidores se conectam via uma DoubleZero Exchange (DZX) dentro de uma área metropolitana, que é uma cidade como Nova York (NYC), Londres (LON) ou Tóquio (TYO). Uma DZX é um fabric de rede semelhante a uma Internet Exchange, permitindo peering e troca de rotas. +A criação de uma rede contígua é um bloco fundamental da arquitetura DoubleZero. Os contribuidores se interconectam via um DoubleZero Exchange (DZX) dentro de uma área metropolitana, que é uma cidade como Nova York (NYC), Londres (LON) ou Tóquio (TYO). Um DZX é um fabric de rede semelhante a um Internet Exchange, permitindo peering e troca de rotas. -Na Figura 4, o contribuidor de rede 1 opera nos data centers 1, 2 e 3, enquanto o contribuidor de rede 2 opera nos data centers 2, 4 e 5. Ao interconectar no data center 2, o alcance da rede DoubleZero aumenta para 5 data centers contíguos. +Na figura 4, o contribuidor de rede 1 opera nos data centers 1, 2 e 3, enquanto o contribuidor de rede 2 opera nos data centers 2, 4 e 5. Ao se interconectarem no data center 2, o alcance da rede DoubleZero aumenta para 5 data centers contíguos.
![Image title](images/figure4.png){ width="1000" } -
Figura 4: Contribuição de Largura de Banda da Rede DoubleZero Entre 2 Contribuidores de Largura de Banda de Rede
+
Figura 4: Contribuição de Largura de Banda da Rede DoubleZero Entre 2 Contribuidores de Largura de Banda de Rede
### Opções de Contribuição de Largura de Banda -O DoubleZero requer que um contribuidor de rede ofereça conectividade integrada via um perfil garantido de largura de banda, latência e jitter entre DZDs em dois data centers terminadores, expresso via contrato inteligente. O DoubleZero não determina como um contribuidor de rede implementa sua contribuição; no entanto, nas seções a seguir, fornecemos opções indicativas para uso a seu exclusivo critério. +O DoubleZero requer que um contribuidor de rede ofereça conectividade integrada via um perfil garantido de largura de banda, latência e jitter entre DZDs em dois data centers terminais, expresso por meio de um smart contract. O DoubleZero não determina como um contribuidor de rede implementa sua contribuição; no entanto, nas seções a seguir, fornecemos opções indicativas para uso a seu exclusivo critério. Áreas importantes a considerar para um contribuidor de rede podem ser: - Capacidade de garantir o desempenho de rede do serviço DoubleZero: largura de banda, latência e jitter - Segregação de seus serviços de rede internos existentes -- Conflitos de endereçamento IPv4, especialmente com o espaço de endereços subjacente ao túnel +- Conflitos de endereçamento IPv4, especificamente com o espaço de endereços do underlay do túnel - Tempo de atividade e disponibilidade - Considerações de CAPEX e OPEX #### Largura de Banda Camada 1
![Image title](images/figure5.png){ width="800" } -
Figura 5: Serviços Ópticos de Camada 1
+
Figura 5: Serviços Ópticos Camada 1
-A largura de banda de Camada 1, mais formalmente descrita como serviços de comprimento de onda, pode ver capacidade dedicada provisionada em uma infraestrutura óptica existente, como DWDM, CWDM ou via multiplexadores ópticos (MUX). Na Figura 5, os DZDs usam uma óptica colorida que é cabeada para um MUX L1, que intercala o comprimento de onda do DZD em uma fibra escura existente. +A largura de banda Camada 1, mais formalmente descrita como serviços de comprimento de onda, pode contemplar capacidade dedicada provisionada em uma infraestrutura óptica existente, como DWDM, CWDM ou via multiplexadores ópticos (MUX). Na figura 5, os DZDs usam uma óptica colorida que é cabeada a um MUX L1, que intercala o comprimento de onda do DZD em uma fibra escura existente. -Esta solução tem inúmeros benefícios para contribuidores de rede que já operam uma rede principal existente. As mudanças operacionais iterativas, bem como os requisitos adicionais de CAPEX e OPEX, são modestos. Esta opção é particularmente robusta em oferecer segregação dos serviços de rede do contribuidor. +Esta solução tem inúmeros benefícios para contribuidores de rede que já operam uma rede core existente. As mudanças operacionais incrementais, bem como os requisitos adicionais de CAPEX e OPEX, são modestos. Esta opção é particularmente robusta em oferecer segregação dos serviços de rede do contribuidor. -#### Largura de Banda em Redes Comutadas por Pacotes +#### Largura de Banda por Comutação de Pacotes -As redes comutadas por pacotes podem ser consideradas uma rede empresarial típica, executando protocolos padrão de roteamento e comutação que suportam aplicações de negócios. Existem inúmeras tecnologias de rede que alcançam conectividade, por exemplo, extensões de camada 2 (L2) usando tags VLAN. +Redes de comutação de pacotes podem ser consideradas uma rede empresarial típica, executando protocolos padrão de roteamento e switching que suportam aplicações de negócios. Existem inúmeras tecnologias de rede que alcançam conectividade, por exemplo, extensões de camada 2 (L2) usando tags VLAN. ##### Extensão L2
![Image title](images/figure6.png){ width="800" } -
Figura 6: Redes Comutadas por Pacotes - Extensão L2
+
Figura 6: Redes de Comutação de Pacotes - Extensão L2
-Uma extensão L2 como mostrado na Figura 6 pode ser facilitada através de marcação VLAN. A porta de um DZD pode ser cabeada para um switch de rede interna do contribuidor, com a porta do switch sendo configurada como porta de acesso em, por exemplo, VLAN 10. Através de marcação 802.1q, esta VLAN pode ser transportada por múltiplos saltos de switch na rede do contribuidor, terminando no switch que se conecta ao DZD remoto. +Uma extensão L2, conforme mostrado na Figura 6, pode ser facilitada por meio de marcação VLAN. A porta de um DZD pode ser cabeada ao switch de rede interna de um contribuidor, com a porta do switch sendo configurada como porta de acesso, por exemplo, na VLAN 10. Através da marcação 802.1q, esta VLAN pode ser transportada por múltiplos saltos de switch na rede do contribuidor, terminando no switch que faz interface com o DZD remoto. -Esta solução se beneficia de ser amplamente suportada e relativamente fácil de implementar, ao mesmo tempo em que cria segmentação entre o DoubleZero e os serviços de camada 3 internos. A largura de banda pode ser controlada com base na velocidade de interface do switch ou roteador interno do contribuidor. Consideração cuidadosa deve ser dada ao desempenho na rede L2 interna compartilhada por meio de tecnologias como Qualidade de Serviço (QoS) ou outras políticas de gerenciamento de tráfego. No entanto, investimentos adicionais em CAPEX e OPEX devem ser modestos se houver capacidade existente disponível na rede principal do contribuidor. +Esta solução se beneficia por ser amplamente suportada e relativamente fácil de implementar, criando segmentação entre o DoubleZero e os serviços internos de camada 3. A largura de banda pode ser controlada com base na velocidade da interface do switch ou roteador interno do contribuidor. Deve-se dar atenção cuidadosa ao desempenho na rede L2 interna compartilhada por meio de tecnologias como Quality of Service (QoS) ou outras políticas de gerenciamento de tráfego. No entanto, os investimentos adicionais de CAPEX e OPEX devem ser modestos se existir capacidade disponível na rede core do contribuidor. #### Largura de Banda Dedicada de Terceiros
![Image title](images/figure7.png){ width="800" } -
Figura 7: Largura de Banda Dedicada de Terceiros
+
Figura 7: Largura de Banda Dedicada de Terceiros
-Embora a reutilização de capacidade disponível seja atraente para muitos contribuidores de rede, também é possível dedicar largura de banda recém-adquirida ao DoubleZero. Nesse cenário, o DZD se conectaria diretamente à operadora terceirizada sem quaisquer dispositivos internos do contribuidor em linha (Figura 7). +Embora reutilizar capacidade disponível seja atraente para muitos contribuidores de rede, também é possível dedicar largura de banda recém-adquirida ao DoubleZero. Em tal cenário, o DZD se conectaria diretamente à operadora de terceiros sem nenhum dispositivo interno do contribuidor no caminho (figura 7). -Esta opção é atraente pois garante largura de banda dedicada para o DoubleZero, é simples operacionalmente e garante segmentação completa de quaisquer outros serviços de rede. Esta opção provavelmente terá o maior aumento de OPEX e requer novos contratos de serviço com operadoras terceirizadas. +Esta opção é atraente pois garante largura de banda dedicada para o DoubleZero, é operacionalmente simples e assegura segmentação completa de quaisquer outros serviços de rede. Esta opção provavelmente terá o maior aumento de OPEX e requer novos contratos de serviço com operadoras de terceiros. --- @@ -119,19 +121,19 @@ Esta opção é atraente pois garante largura de banda dedicada para o DoubleZer ### Contribuição de Largura de Banda de 100Gbps -Observe que as quantidades abaixo refletem o equipamento necessário em dois data centers, ou seja, o total de hardware necessário para implantar 1 cabo de fibra ótica para contribuição de largura de banda. +Observe que as quantidades abaixo refletem os equipamentos necessários em dois data centers, ou seja, o total de hardware necessário para implantar 1 cabo de fibra óptica para contribuição de largura de banda. -??? warning "*Todos os FPGAs estão sujeitos a testes finais. Contribuições de 10G podem ser suportadas usando switches Arista 7130LBR com FPGAs Virtex® UltraScale+™ duplos embutidos (se você tiver alguma dúvida, a DoubleZero Foundation / Malbec Labs terá prazer em fornecer mais informações)." +??? warning "*Todos os FPGAs estão sujeitos a testes finais. Contribuições de 10G podem ser suportadas usando switches Arista 7130LBR com FPGAs Virtex® UltraScale+™ duplos integrados (se você tiver alguma dúvida, a DoubleZero Foundation / Malbec Labs terá prazer em fornecer mais informações)." -#### Requisitos de Função e Porta +#### Requisitos de Função e Portas | Função | Velocidade da Porta | Requisito DZ | QTD | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Largura de Banda Privada | 100G | Sim | 1 | | | Acesso Direto à Internet (DIA) | 10G | Sim | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sim* | 1 | Deve ser suportado quando mais de 3 provedores operam na mesma área metropolitana; antes disso, cross-connects ou outros arranjos de peering podem ser usados para interconectar outros provedores. | -| Gerenciamento | | Não | 1 | Determinado pelas próprias políticas de gerenciamento interno do contribuidor. | -| Console | | Não | 1 | Determinado pelas próprias políticas de gerenciamento interno do contribuidor. | +| DoubleZero eXchange (DZX) | 100G | Sim* | 1 | Deve ser suportado quando mais de 3 provedores operam na mesma área metropolitana; antes disso, cross-connects ou outros arranjos de peering podem ser usados para interconectar com outros provedores. | +| Gerenciamento | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | +| Console | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | #### Hardware de Rede DZD @@ -142,20 +144,20 @@ Observe que as quantidades abaixo refletem o equipamento necessário em dois dat --- -#### Óptica - 100G +#### Ópticas - 100G | Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 16 | Escolha de cabeamento e óptica disponível a critério do contribuidor. 100G necessário para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 16 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. 100G necessário para conectar FPGAs. | --- -#### Óptica - 10G +#### Ópticas - 10G | Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Não | 2 | Escolha de cabeamento e óptica disponível a critério do contribuidor. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 2 | Escolha de cabeamento e óptica disponível a critério do contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | Não | 2 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 2 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | --- @@ -163,23 +165,23 @@ Observe que as quantidades abaixo refletem o equipamento necessário em dois dat | Endereçamento IP | Tamanho Mínimo de Sub-rede | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 Público | /29 | Sim (para DZDs edge/hybrid) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | +| IPv4 Público | /29 | Sim (para DZDs edge/híbridos) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | -Certifique-se de que o pool completo /29 esteja disponível para o protocolo DZ. Quaisquer requisitos para endereçamento ponto a ponto, por exemplo, em interfaces DIA, devem ser gerenciados via um pool de endereços diferente. +Certifique-se de que o pool /29 completo esteja disponível para o protocolo DZ. Quaisquer requisitos de endereçamento ponto a ponto, por exemplo, em interfaces DIA, devem ser gerenciados por meio de um pool de endereços diferente. ### Contribuição de Largura de Banda de 10Gbps -Observe que as quantidades refletem o equipamento de dois data centers, ou seja, o total de hardware necessário para implantar 1 contribuição de largura de banda. +Observe que as quantidades refletem os equipamentos de dois data centers, ou seja, o total de hardware necessário para implantar 1 contribuição de largura de banda. -#### Requisitos de Função e Porta +#### Requisitos de Função e Portas | Função | Velocidade da Porta | Requisito DZ | QTD | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Largura de Banda Privada | 10G | Sim | 1 | | | Acesso Direto à Internet (DIA) | 10G | Sim | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sim* | 1 | Deve ser suportado quando mais de 3 provedores operam na mesma área metropolitana; antes disso, cross-connects ou outros arranjos de peering podem ser usados para interconectar outros provedores. | -| Gerenciamento | | Não | 1 | Determinado pelas próprias políticas de gerenciamento interno do contribuidor. | -| Console | | Não | 1 | Determinado pelas próprias políticas de gerenciamento interno do contribuidor. | +| DoubleZero eXchange (DZX) | 100G | Sim* | 1 | Deve ser suportado quando mais de 3 provedores operam na mesma área metropolitana; antes disso, cross-connects ou outros arranjos de peering podem ser usados para interconectar com outros provedores. | +| Gerenciamento | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | +| Console | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | --- @@ -192,41 +194,66 @@ Observe que as quantidades refletem o equipamento de dois data centers, ou seja, --- -#### Óptica - 100G +#### Ópticas - 100G | Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 14 | Escolha de cabeamento e óptica disponível a critério do contribuidor. 100G necessário para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 14 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. 100G necessário para conectar FPGAs. | --- -#### Óptica - 10G +#### Ópticas - 10G | Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Não | 4 | Escolha de cabeamento e óptica disponível a critério do contribuidor. | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 4 | Escolha de cabeamento e óptica disponível a critério do contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | Não | 4 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 4 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | --- #### Endereçamento IP | Endereçamento IP | Tamanho Mínimo de Sub-rede | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 Público | /29 | Sim (para DZDs edge/hybrid) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | +| IPv4 Público | /29 | Sim (para DZDs edge/híbridos) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | -Certifique-se de que o pool completo /29 esteja disponível para o protocolo DZ. Quaisquer requisitos para endereçamento ponto a ponto, por exemplo, em interfaces DIA, devem ser gerenciados via um pool de endereços diferente. +Certifique-se de que o pool /29 completo esteja disponível para o protocolo DZ. Quaisquer requisitos de endereçamento ponto a ponto, por exemplo, em interfaces DIA, devem ser gerenciados por meio de um pool de endereços diferente. -### Requisitos de Data Center +### Requisitos do Data Center #### Requisitos de Rack e Energia -| Requisito | Especificação | -|-------------|--------------| -| Espaço em Rack | 4U | -| Energia | 4KW (recomendado) | +Os valores abaixo são **por DZD**, ou seja, por data center. Uma contribuição de largura de banda de 100G ou 10G coloca um DZD em cada extremidade do link, portanto planeje isso duas vezes. + +##### Espaço em rack + +| Item | Unidades de rack | Necessário | +|------|-----------|--------| +| Switch DZD (Arista 7280CR3A-32S ou 7130LBR) | 1U | Agora | +| Appliance de filtragem de borda | 1U | Posteriormente, apenas em dispositivos edge e híbridos | + +**Reserve 2U por DZD.** Uma unidade está em uso hoje. Mantenha a segunda livre para que o appliance de filtragem de borda possa ser instalado ao lado do switch sem necessidade de remanejamento no rack. Deixe espaço para fluxo de ar e gerenciamento de cabos conforme sua instalação exigir. + +##### Energia + +| Item | Consumo típico | +|------|-------------| +| Arista 7280CR3A-32S | ~300 W | +| Ópticas, por QSFP 100G | ~5 W | + +**Solicite 2 kW por DZD, divididos entre duas alimentações independentes.** Dimensione cada alimentação para suportar a carga total sozinha. O switch opera com fontes de alimentação redundantes e, após uma falha de alimentação, uma delas pode ser tudo o que resta. + +2 kW é confortável em vez de justo. Um DZD apenas com switch, que é o que quase todas as implantações executam hoje, consome bem menos de 500 W com todas as suas ópticas ativas. O restante dos 2 kW é reservado para o appliance de filtragem de borda, que contém os FPGAs e será instalado posteriormente. + +!!! warning "Não solicite energia em excesso" + Você paga pela energia que reserva, independentemente de consumi-la ou não. Um DZD é uma única unidade de rack de switching, não um chassi de computação, portanto consome muito menos do que sua posição no rack poderia fornecer. Reservar mais de 2 kW por DZD significa pagar por capacidade que fica ociosa. + +!!! note "Verifique seu próprio hardware antes de fazer o pedido" + Estes são valores de referência de nossas próprias implantações. Seu consumo real depende da configuração da sua fonte de alimentação, de quantas portas você ativa e de quais ópticas você escolhe. Confirme com as especificações de potência da fonte de alimentação na folha de dados do fabricante para o hardware exato que você adquirir. + + Também não reduza o pedido ao mínimo absoluto. A energia precisa estar disponível no rack, e adicionar uma alimentação posteriormente geralmente significa um novo pedido junto à instalação, o que pode levar semanas. --- -## Próximas Etapas +## Próximos Passos -Pronto para provisionar seu primeiro DZD? Continue para o [Guia de Provisionamento de Dispositivos](contribute-provisioning.md). +Pronto para provisionar seu primeiro DZD? Continue para o [Guia de Provisionamento de Dispositivos](contribute-provisioning.md). \ No newline at end of file diff --git a/docs/contribute.zh.md b/docs/contribute.zh.md index fa3f845..be27e01 100644 --- a/docs/contribute.zh.md +++ b/docs/contribute.zh.md @@ -1,232 +1,259 @@ -# 贡献者需求与架构 -!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon." +--- +description: 为 DoubleZero 网络贡献容量所需的硬件、带宽和连接要求及架构。 +--- +# 贡献者要求与架构 -## 摘要 +## 概述 -任何希望将其未充分利用的光纤电缆和网络硬件货币化的人都可以为DoubleZero网络做出贡献。网络贡献者必须在两点之间提供专用带宽，在每端运营DoubleZero兼容设备（DZD），并在每端连接到公共互联网。网络贡献者还必须在每个DZD上运行DoubleZero软件，以提供多播、用户查找和边缘过滤等服务。 +任何希望将其未充分利用的光纤电缆和网络硬件进行变现的人都可以为 DoubleZero 网络做出贡献。网络贡献者必须在两个站点之间提供专用带宽，在每端运行 DoubleZero 兼容设备 (DZD)，并在每端提供公共互联网连接。网络贡献者还必须在每个 DZD 上运行 DoubleZero 软件，以提供组播、用户查找和边缘过滤等服务。 -DoubleZero智能合约是确保网络维持可测量并集成到拓扑中的高质量链路的基础，使我们的网络控制器能够开发不同用户和端点之间最高效的端到端路径。在执行智能合约并部署网络设备和带宽后，实体被归类为网络贡献者。请参阅[DoubleZero经济学](https://economics.doublezero.xyz/overview)进一步了解作为网络贡献者参与DoubleZero的经济学原理。 +DoubleZero 智能合约是确保网络维持高质量链路的基石，这些链路可以被测量并集成到拓扑结构中，使我们的网络控制器能够在不同用户和端点之间开发最高效的端到端路径。在智能合约执行以及网络设备和带宽部署完成后，实体即被归类为网络贡献者。请参阅 [DoubleZero Economics](https://economics.doublezero.xyz/overview) 以进一步了解作为网络贡献者参与 DoubleZero 的经济模型。 --- -## 成为DoubleZero网络贡献者的要求 +## 成为 DoubleZero 网络贡献者的要求 -- 能够在两个数据中心之间提供IPv4连接和2048字节MTU的专用带宽 -- 与DoubleZero协议兼容的DoubleZero设备（DZD）硬件 -- 与互联网和其他DoubleZero网络贡献者的连接 -- 在DZD上安装DoubleZero软件 +- 能够在两个数据中心之间提供 IPv4 连接和 2048 字节 MTU 的专用带宽 +- 与 DoubleZero 协议兼容的 DoubleZero 设备 (DZD) 硬件 +- 与互联网和其他 DoubleZero 网络贡献者的连接 +- 在 DZD 上安装 DoubleZero 软件 ## 快速入门指南 -作为网络贡献者，在DoubleZero中开始的最简单方式是识别您网络中可以专用于DoubleZero的容量。一旦确定，必须部署DZD，以便DoubleZero覆盖网络只需要IPv4可达性和最小2048字节MTU作为来自贡献者网络的依赖项。 +作为网络贡献者，开始参与 DoubleZero 最简单的方式是识别您网络中可以专用于 DoubleZero 的容量。一旦确定，必须部署 DZD，以促进 DoubleZero 叠加网络的建立——该网络仅要求贡献者网络提供 IPv4 可达性和最低 2048 字节的 MTU 作为依赖条件。 -图1展示了贡献带宽和数据包发送及处理服务的最简单模型。DZD部署在每个数据中心，与网络贡献者的内部网络接口，提供DoubleZero WAN连接。这由本地互联网补充，通常是直接互联网访问（DIA）解决方案，用作DoubleZero用户的接入点。虽然DIA预计是促进DoubleZero用户访问的首选选项，但多种连接模型也是可能的，例如到服务器的物理布线、网络结构扩展等。我们将这些选项称为自选冒险（CYOA），为贡献者提供以最适合其内部网络策略的方式连接本地或远程用户的灵活性。 +图 1 展示了贡献带宽和数据包发送与处理服务的最简模型。在每个数据中心部署一个 DZD，与网络贡献者的内部网络对接，以提供 DoubleZero WAN 连接。这通过本地互联网连接来补充，通常是直连互联网接入 (DIA) 解决方案，用作 DoubleZero 用户的接入点。虽然预计 DIA 将是为 DoubleZero 用户提供接入的首选方案，但也支持多种连接模型，例如到服务器的物理布线、网络架构扩展等。我们将这些选项称为自选冒险方案 (CYOA)，为贡献者提供灵活性，以最适合其内部网络策略的方式连接本地或远程用户。 -与任何网络一样，可达性是架构的基本组成部分，因为网络贡献者不能孤立存在。因此，DZD*必须*有一条到DoubleZero交换点（DZX）的链路，以在参与者之间创建连续网络。 +与任何网络一样，可达性是架构的基本组成部分，因为网络贡献者不能孤立存在。因此，DZD *必须* 与 DoubleZero 交换节点 (DZX) 建立链路，以在参与者之间创建连续的网络。
![Image title](images/figure1.png){ width="800" } -
图1：2个数据中心之间的DoubleZero网络带宽贡献 - 单一贡献者
+
图 1：2 个数据中心之间的 DoubleZero 网络带宽贡献 - 单个贡献者
### 贡献示例 -网络贡献者可以通过多种方式增加其DoubleZero贡献，包括： +网络贡献者可以通过多种方式扩展其 DoubleZero 贡献，包括： -- 改善现有贡献的性能特征：增加带宽、减少延迟 +- 提升现有贡献的性能特征：增加带宽、降低延迟 - 在相同数据中心之间添加多条链路 -- 从现有数据中心添加到新数据中心的新链路 -- 在两个新数据中心之间添加一条新的独立链路 +- 从现有数据中心到新数据中心添加新链路 +- 在两个新数据中心之间添加新的独立链路 -#### 示例1：单一贡献者，3个数据中心，两条链路 +#### 示例 1：单个贡献者，3 个数据中心，两条链路
![Image title](images/figure2.png){ width="800" } -
图2：3个数据中心之间的DoubleZero网络带宽贡献 - 单一贡献者
+
图 2：3 个数据中心之间的 DoubleZero 网络带宽贡献 - 单个贡献者
-单个DZD可以支持向DoubleZero贡献的多条链路。图2展示了当标为1的单个数据中心向两个不同的远程数据中心2和3终止带宽时的潜在拓扑。在此场景中，每个数据中心只包含1个DZD。所有DZD都使用DIA作为其CYOA接口的用户接入点。 +单个 DZD 可以支持向 DoubleZero 贡献的多条链路。图 2 展示了当单个数据中心（标记为 1）终结到两个不同远程数据中心 2 和 3 的带宽时的潜在拓扑结构。在此场景中，每个数据中心仅包含 1 个 DZD。所有 DZD 都使用 DIA 作为其 CYOA 接口的用户接入点。 -#### 示例2：单一贡献者，3个数据中心，三条链路 +#### 示例 2：单个贡献者，3 个数据中心，三条链路 -图3描述了当单个贡献者在3个数据中心之间以三角形拓扑部署三条链路时的DoubleZero拓扑。在类似示例1的场景中，单个DZD部署在数据中心1、2和3中，每个支持2条独立的网络链路。由此产生的拓扑是数据中心之间的三角形或环形。 +图 3 描述了当单个贡献者在 3 个数据中心之间以三角形拓扑部署三条链路时的 DoubleZero 拓扑结构。在与示例 1 类似的场景中，数据中心 1、2 和 3 各部署一个 DZD，每个支持 2 条独立的网络链路。最终拓扑为数据中心之间的三角形或环形结构。
![Image title](images/figure3.png){ width="800" } -
图3：3个数据中心之间的DoubleZero网络带宽贡献 - 单一贡献者
+
图 3：3 个数据中心之间的 DoubleZero 网络带宽贡献 - 单个贡献者
-### DoubleZero交换点 +### DoubleZero 交换节点 -创建连续网络是DoubleZero架构的基本构建块。贡献者通过都市区内的DoubleZero交换点（DZX）进行接口，都市区是纽约（NYC）、伦敦（LON）或东京（TYO）等城市。DZX是类似于互联网交换点的网络结构，允许对等互联和路由交换。 +创建连续网络是 DoubleZero 架构的基本构建模块。贡献者通过都会区域内的 DoubleZero 交换节点 (DZX) 进行互联，都会区域即一个城市，如纽约 (NYC)、伦敦 (LON) 或东京 (TYO)。DZX 是类似于互联网交换中心的网络架构，允许对等互联和路由交换。 -在图4中，网络贡献者1在数据中心1、2和3运营，而网络贡献者2在数据中心2、4和5运营。通过在数据中心2互连，DoubleZero网络覆盖范围增加到5个连续数据中心。 +在图 4 中，网络贡献者 1 在数据中心 1、2 和 3 中运营，而网络贡献者 2 在数据中心 2、4 和 5 中运营。通过在数据中心 2 互联，DoubleZero 网络覆盖范围扩展到 5 个连续的数据中心。
![Image title](images/figure4.png){ width="1000" } -
图4：2个网络带宽贡献者之间的DoubleZero网络带宽贡献
+
图 4：2 个网络带宽贡献者之间的 DoubleZero 网络带宽贡献
### 带宽贡献选项 -DoubleZero要求网络贡献者通过智能合约提供在两个终止数据中心的DZD之间具有保证带宽、延迟和抖动配置文件的集成连接。DoubleZero不强制规定网络贡献者如何实施其贡献，但在以下章节中，我们提供可供其自行决定使用的参考选项。 +DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心的 DZD 之间提供具有保证带宽、延迟和抖动配置的集成连接。DoubleZero 不强制规定网络贡献者如何实施其贡献，但在以下部分我们提供了指导性选项，供其自行决定使用。 -网络贡献者可能需要考虑的重要领域： +网络贡献者需要考虑的重要方面可能包括： -- 保证DoubleZero服务网络性能的能力：带宽、延迟和抖动 +- 保证 DoubleZero 服务网络性能的能力：带宽、延迟和抖动 - 与现有内部网络服务的隔离 -- IPv4地址冲突，特别是与隧道底层地址空间 +- IPv4 地址冲突，特别是与隧道底层地址空间的冲突 - 正常运行时间和可用性 -- 资本支出和运营支出考虑 +- 资本支出 (CAPEX) 和运营支出 (OPEX) 考量 -#### 第1层带宽 +#### 第 1 层带宽
![Image title](images/figure5.png){ width="800" } -
图5：第1层光学服务
+
图 5：第 1 层光学服务
-第1层带宽，更正式地称为波长服务，可以在现有光学基础设施（如DWDM、CWDM或通过光学多路复用器（MUX））上配置专用容量。在图5中，DZD使用彩色光纤连接到L1 MUX，将DZD波长插入到现有暗光纤上。 +第 1 层带宽，更正式地称为波长服务，可以在现有光学基础设施上配置专用容量，例如 DWDM、CWDM 或通过光复用器 (MUX)。在图 5 中，DZD 使用彩色光模块连接到 L1 MUX，将 DZD 波长交织到现有暗光纤上。 -对于已经运营现有核心网络的网络贡献者，此解决方案具有众多优势。迭代操作更改以及额外的资本支出和运营支出要求是适度的。此选项在提供与网络贡献者网络服务的隔离方面特别强大。 +该解决方案对于已经运营现有核心网络的网络贡献者具有诸多优势。增量运营变更以及额外的 CAPEX 和 OPEX 要求都相对适中。此选项在提供与网络贡献者网络服务的隔离方面尤为稳健。 #### 分组交换带宽 -分组交换网络可以被视为典型的企业网络，运行支持业务应用程序的标准路由和交换协议。有多种网络技术可以实现连接，例如使用VLAN标签的第2层（L2）扩展。 +分组交换网络可以被视为典型的企业网络，运行标准路由和交换协议以支持业务应用。有多种网络技术可以实现连接，例如使用 VLAN 标签的第 2 层 (L2) 扩展。 -##### L2扩展 +##### L2 扩展
![Image title](images/figure6.png){ width="800" } -
图6：分组交换网络 - L2扩展
+
图 6：分组交换网络 - L2 扩展
-如图6所示的L2扩展可以通过VLAN标记实现。DZD的端口可以连接到贡献者的内部网络交换机，交换机端口设置为例如VLAN 10的接入端口。通过802.1q标记，此VLAN可以在贡献者网络的多个交换机跳上传输，终止于与远程DZD接口的交换机。 +如图 6 所示，L2 扩展可以通过 VLAN 标记来实现。DZD 的端口可以连接到贡献者的内部网络交换机，交换机端口设置为接入端口，例如在 VLAN 10 中。通过 802.1q 标记，该 VLAN 可以在贡献者网络上跨越多个交换机跳数传输，终止于与远程 DZD 对接的交换机。 -此解决方案受益于广泛支持和相对容易实施，同时在DoubleZero和内部第3层服务之间创建分段。带宽可以根据贡献者内部交换机或路由器的接口速度进行控制。必须通过服务质量（QoS）或其他流量管理策略等技术仔细考虑共享内部L2网络的性能。但是，如果贡献者的核心网络中有现有容量，额外的资本支出和运营支出投资应该是适度的。 +该解决方案的优势在于广泛支持且相对容易实施，同时在 DoubleZero 和内部第 3 层服务之间创建了分段隔离。带宽可以基于贡献者内部交换机或路由器的接口速度进行控制。需要仔细考虑通过服务质量 (QoS) 或其他流量管理策略在共享内部 L2 网络上的性能表现。但是，如果贡献者核心网络中有可用容量，额外的 CAPEX 和 OPEX 投入应该是适中的。 #### 专用第三方带宽
![Image title](images/figure7.png){ width="800" } -
图7：专用第三方带宽
+
图 7：专用第三方带宽
-虽然重用可用容量对许多网络贡献者来说很有吸引力，但也可以将新获取的带宽专用于DoubleZero。在这种场景中，DZD将直接连接到第三方运营商，而没有任何贡献者的内部设备内联（图7）。 +虽然重用可用容量对许多网络贡献者来说很有吸引力，但也可以将新采购的带宽专用于 DoubleZero。在这种情况下，DZD 将直接连接到第三方运营商，贡献者的内部设备不在链路中（图 7）。 -此选项很有吸引力，因为它确保了DoubleZero的专用带宽，操作简单，并确保与任何其他网络服务完全隔离。此选项可能会有最高的运营支出增加，并需要与第三方运营商签订新的服务合同。 +此选项的优势在于确保 DoubleZero 的专用带宽，操作简单且确保与其他网络服务完全隔离。此选项可能带来最高的 OPEX 增长，并且需要与第三方运营商签订新的服务合同。 --- ## 硬件要求 -### 100Gbps带宽贡献 +### 100Gbps 带宽贡献 -请注意，以下数量反映了两个数据中心所需的设备，即部署1条光纤电缆进行带宽贡献所需的总硬件。 +请注意，以下数量反映的是两个数据中心所需的设备，即部署 1 条光纤用于带宽贡献所需的全部硬件。 -??? warning "*所有FPGA均需经过最终测试。使用内置双Virtex® UltraScale+™ FPGA的Arista 7130LBR交换机可能支持10G贡献（如有任何问题，DoubleZero基金会 / Malbec Labs很乐意提供更多信息）。" +??? warning "*所有 FPGA 均须经过最终测试。10G 贡献可能支持使用内置双 Virtex® UltraScale+™ FPGA 的 Arista 7130LBR 交换机（如有任何疑问，DoubleZero Foundation / Malbec Labs 很乐意提供更多信息）。*" #### 功能与端口要求 -| 功能 | 端口速度 | DZ要求 | 数量 | 备注 | +| 功能 | 端口速度 | DZ 要求 | 数量 | 备注 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 私有带宽 | 100G | 是 | 1 | | -| 直接互联网访问（DIA） | 10G | 是 | 2 | | -| DoubleZero交换点（DZX） | 100G | 是* | 1 | 一旦同一都市区有超过3个提供商运营，必须支持；在此之前，可以使用交叉连接或其他对等互联安排与其他提供商互连。 | -| 管理 | | 否 | 1 | 由贡献者自己的内部管理策略决定。 | -| 控制台 | | 否 | 1 | 由贡献者自己的内部管理策略决定。 | +| 专用带宽 | 100G | 是 | 1 | | +| 直连互联网接入 (DIA) | 10G | 是 | 2 | | +| DoubleZero 交换节点 (DZX) | 100G | 是* | 1 | 当同一都会区域有超过 3 个提供商运营时必须支持，在此之前可以使用交叉连接或其他对等互联安排与其他提供商互联。 | +| 管理 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | +| 控制台 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | -#### DZD网络硬件 +#### DZD 网络硬件 -| 制造商 | 型号 | 部件编号 | DZ要求 | 数量 | 备注 | +| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | 是 | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如果交货期较长，可能有替代方案。 | +| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如果交货周期紧张，可能有替代方案。 | --- -#### 光纤 - 100G +#### 光模块 - 100G -| 制造商 | 型号 | 部件编号 | DZ要求 | 数量 | 备注 | +| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | 否 | 16 | 布线和光纤选择由贡献者自行决定。连接FPGA需要100G。 | +| Arista | 100GBASE-LR | QSFP-100G-LR | 否 | 16 | 布线和光模块选择由贡献者自行决定。连接 FPGA 需要 100G。 | --- -#### 光纤 - 10G +#### 光模块 - 10G -| 制造商 | 型号 | 部件编号 | DZ要求 | 数量 | 备注 | +| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | 否 | 2 | 布线和光纤选择由贡献者自行决定。 | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 否 | 2 | 布线和光纤选择由贡献者自行决定。 | +| Arista | 10GBASE-LR | SFP-10G-LR | 否 | 2 | 布线和光模块选择由贡献者自行决定。 | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 否 | 2 | 布线和光模块选择由贡献者自行决定。 | --- -#### IP寻址 +#### IP 地址 -| IP寻址 | 最小子网大小 | DZ要求 | 备注 | +| IP 地址 | 最小子网大小 | DZ 要求 | 备注 | |--------------|-------------------|----------------|----------------------------------------------------------| -| 公共IPv4 | /29 | 是（对于边缘/混合DZD） | 必须通过DIA可路由。我们可能会随着时间的推移消除此需求。 | +| Public IPv4 | /29 | 是（用于边缘/混合 DZD） | 必须可通过 DIA 路由。我们可能会在未来逐步取消此要求。 | -请确保整个/29池可用于DZ协议。任何点对点寻址的要求（例如DIA接口上的）应通过不同的地址池进行管理。 +请确保完整的 /29 地址池可用于 DZ 协议。任何点对点地址需求（例如 DIA 接口上的地址）应通过不同的地址池进行管理。 -### 10Gbps带宽贡献 +### 10Gbps 带宽贡献 -请注意，数量反映了两个数据中心的设备，即部署1个带宽贡献所需的总硬件。 +请注意，数量反映的是两个数据中心的设备，即部署 1 条带宽贡献所需的全部硬件。 #### 功能与端口要求 -| 功能 | 端口速度 | DZ要求 | 数量 | 备注 | +| 功能 | 端口速度 | DZ 要求 | 数量 | 备注 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 私有带宽 | 10G | 是 | 1 | | -| 直接互联网访问（DIA） | 10G | 是 | 2 | | -| DoubleZero交换点（DZX） | 100G | 是* | 1 | 一旦同一都市区有超过3个提供商运营，必须支持；在此之前，可以使用交叉连接或其他对等互联安排与其他提供商互连。 | -| 管理 | | 否 | 1 | 由贡献者自己的内部管理策略决定。 | -| 控制台 | | 否 | 1 | 由贡献者自己的内部管理策略决定。 | +| 专用带宽 | 10G | 是 | 1 | | +| 直连互联网接入 (DIA) | 10G | 是 | 2 | | +| DoubleZero 交换节点 (DZX) | 100G | 是* | 1 | 当同一都会区域有超过 3 个提供商运营时必须支持；在此之前可以使用交叉连接或其他对等互联安排与其他提供商互联。 | +| 管理 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | +| 控制台 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | --- #### 硬件 -| 制造商 | 型号 | 部件编号 | DZ要求 | 数量 | 备注 | +| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| -| AMD* | V80* | 24540474* | 是 | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如果交货期较长，可能有替代方案。 | +| AMD* | V80* | 24540474* | 是 | 4 | | | +| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如果交货周期紧张，可能有替代方案。 | --- -#### 光纤 - 100G +#### 光模块 - 100G -| 制造商 | 型号 | 部件编号 | DZ要求 | 数量 | 备注 | +| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | 否 | 14 | 布线和光纤选择由贡献者自行决定。连接FPGA需要100G。 | +| Arista | 100GBASE-LR | QSFP-100G-LR | 否 | 14 | 布线和光模块选择由贡献者自行决定。连接 FPGA 需要 100G。 | --- -#### 光纤 - 10G +#### 光模块 - 10G -| 制造商 | 型号 | 部件编号 | DZ要求 | 数量 | 备注 | +| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | 否 | 4 | 布线和光纤选择由贡献者自行决定。 | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 否 | 4 | 布线和光纤选择由贡献者自行决定。 | +| Arista | 10GBASE-LR | SFP-10G-LR | 否 | 4 | 布线和光模块选择由贡献者自行决定。 | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 否 | 4 | 布线和光模块选择由贡献者自行决定。 | --- -#### IP寻址 +#### IP 地址 -| IP寻址 | 最小子网大小 | DZ要求 | 备注 | +| IP 地址 | 最小子网大小 | DZ 要求 | 备注 | |--------------|-------------------|----------------|----------------------------------------------------------| -| 公共IPv4 | /29 | 是（对于边缘/混合DZD） | 必须通过DIA可路由。我们可能会随着时间的推移消除此需求。 | +| Public IPv4 | /29 | 是（用于边缘/混合 DZD） | 必须可通过 DIA 路由。我们可能会在未来逐步取消此要求。 | -请确保整个/29池可用于DZ协议。任何点对点寻址的要求（例如DIA接口上的）应通过不同的地址池进行管理。 +请确保完整的 /29 地址池可用于 DZ 协议。任何点对点地址需求（例如 DIA 接口上的地址）应通过不同的地址池进行管理。 ### 数据中心要求 -#### 机架与电源要求 +#### 机柜与电力要求 + +以下数据为**每个 DZD** 的数据，即每个数据中心的数据。100G 或 10G 带宽贡献在链路每端各放置一个 DZD，因此请按两倍规划。 + +##### 机柜空间 + +| 项目 | 机架单元 | 需求时间 | +|------|-----------|--------| +| DZD 交换机 (Arista 7280CR3A-32S 或 7130LBR) | 1U | 现在 | +| 边缘过滤设备 | 1U | 后续，仅适用于边缘和混合设备 | + +**每个 DZD 预留 2U。** 其中一个单元目前在使用中。保留第二个空位，以便边缘过滤设备日后可以安装在交换机旁边，无需进行机柜迁移。根据您的设施要求预留气流和线缆管理空间。 + +##### 电力 + +| 项目 | 典型功耗 | +|------|-------------| +| Arista 7280CR3A-32S | ~300 W | +| 光模块，每个 100G QSFP | ~5 W | + +**每个 DZD 订购 2 kW，分配到两路独立电源。** 每路电源的容量应能独立承载全部负载。交换机配备冗余电源，在一路电源故障后，您可能只剩下其中一个电源模块可用。 + +2 kW 是留有余量而非紧凑的配置。仅交换机的 DZD（这是目前绝大多数部署的配置），在所有光模块点亮后功耗远低于 500 W。其余 2 kW 容量是为边缘过滤设备预留的，该设备包含 FPGA 并将在后续安装。 + +!!! warning "不要过度订购电力" + 无论是否实际使用，您都需要为预留的电力付费。DZD 是单个机架单元的交换设备，不是计算机箱，因此其功耗远低于该机架位置所能供应的电力。每个 DZD 预留超过 2 kW 意味着为闲置容量付费。 + +!!! note "下单前请核实您自己的硬件" + 这些是我们自身部署的指导性数据。您的实际功耗取决于您的电源配置、点亮的端口数量以及选择的光模块。请根据您购买的具体硬件的供应商数据表中的电源额定值进行确认。 -| 要求 | 规格 | -|-------------|--------------| -| 机架空间 | 4U | -| 电源 | 4KW（推荐） | + 也不要将订单削减到最低限度。电力必须在机柜中可用，而后续增加电源通常意味着向数据中心提交新订单，这可能需要数周时间。 --- ## 后续步骤 -准备好配置您的第一个DZD了吗？继续阅读[设备配置指南](contribute-provisioning.md)。 +准备好配置您的第一个 DZD 了吗？请继续阅读 [设备配置指南](contribute-provisioning.md)。 \ No newline at end of file diff --git a/docs/glossary.es.md b/docs/glossary.es.md index 01df3c4..d70c3d6 100644 --- a/docs/glossary.es.md +++ b/docs/glossary.es.md @@ -14,42 +14,42 @@ Esta página define la terminología específica de DoubleZero utilizada a lo la El hardware físico de conmutación de red que termina los enlaces de DoubleZero y ejecuta el software DoubleZero Agent. Los DZDs se despliegan en centros de datos y proporcionan servicios de enrutamiento, procesamiento de paquetes y conectividad de usuarios. Cada DZD requiere [especificaciones de hardware](contribute.md#dzd-network-hardware) específicas y ejecuta tanto el [Config Agent](#config-agent) como el [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Puntos de interconexión en la red mallada donde se conectan los enlaces de diferentes [contribuidores](#contributor). Los DZXs están ubicados en las principales áreas metropolitanas (por ejemplo, NYC, LON, TYO) donde ocurren las intersecciones de red. Los contribuidores de red deben interconectar sus enlaces en la malla más amplia de DoubleZero en el DZX más cercano. Similar en concepto a un punto de intercambio de Internet (IX). +Puntos de interconexión en la red mallada donde se interconectan enlaces de diferentes [contribuidores](#contributor). Los DZXs están ubicados en las principales áreas metropolitanas (por ejemplo, NYC, LON, TYO) donde ocurren intersecciones de red. Los contribuidores de red deben interconectar sus enlaces en la malla más amplia de DoubleZero en el DZX más cercano. Similar en concepto a un Internet Exchange (IX). ### WAN Link Un enlace de Red de Área Amplia (Wide Area Network) entre dos [DZDs](#dzd-doublezero-device) operados por el **mismo** contribuidor. Los enlaces WAN proporcionan conectividad troncal dentro de la infraestructura de un único contribuidor. ### DZX Link -Un enlace entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, establecido en un [DZX](#dzx-doublezero-exchange). Los enlaces DZX requieren la aceptación explícita de ambas partes. +Un enlace entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, establecido en un [DZX](#dzx-doublezero-exchange). Los enlaces DZX requieren aceptación explícita por ambas partes. ### DZ Prefix -Asignaciones de direcciones IP en formato CIDR asignadas a un [DZD](#dzd-doublezero-device) para el direccionamiento de la red superpuesta. Se especifican durante la [creación del dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando el parámetro `--dz-prefixes`. +Asignaciones de direcciones IP en formato CIDR asignadas a un [DZD](#dzd-doublezero-device) para el direccionamiento de la red overlay. Se especifican durante la [creación del dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando el parámetro `--dz-prefixes`. --- ## Tipos de Dispositivos ### Edge Device -Un [DZD](#dzd-doublezero-device) que proporciona conectividad de usuario a la red DoubleZero. Los dispositivos edge aprovechan las interfaces [CYOA](#cyoa-choose-your-own-adventure) para conectar usuarios (validadores, operadores RPC) a la red. +Un [DZD](#dzd-doublezero-device) que proporciona conectividad de usuarios a la red DoubleZero. Los dispositivos edge aprovechan las interfaces [CYOA](#cyoa-choose-your-own-adventure) para terminar usuarios (validadores, operadores RPC) y conectarlos a la red. ### Transit Device -Un [DZD](#dzd-doublezero-device) que proporciona conectividad troncal dentro de la red DoubleZero. Los dispositivos transit mueven tráfico entre DZDs pero no terminan conexiones de usuario directamente. +Un [DZD](#dzd-doublezero-device) que proporciona conectividad troncal dentro de la red DoubleZero. Los dispositivos transit mueven tráfico entre DZDs pero no terminan conexiones de usuarios directamente. ### Hybrid Device -Un [DZD](#dzd-doublezero-device) que combina la funcionalidad tanto de [edge](#edge-device) como de [transit](#transit-device), proporcionando conectividad de usuario y enrutamiento troncal. +Un [DZD](#dzd-doublezero-device) que combina la funcionalidad tanto de [edge](#edge-device) como de [transit](#transit-device), proporcionando tanto conectividad de usuarios como enrutamiento troncal. --- ## Conectividad ### CYOA (Choose Your Own Adventure) -Tipos de interfaz que permiten a los [contribuidores](#contributor) registrar opciones de conectividad para que los usuarios se conecten a la red DoubleZero. Las interfaces CYOA incluyen varios métodos como [DIA](#dia-direct-internet-access), túneles GRE y peering privado. Consulte [Creación de Interfaces CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) para detalles de configuración. +Tipos de interfaces que permiten a los [contribuidores](#contributor) registrar opciones de conectividad para que los usuarios se conecten a la red DoubleZero. Las interfaces CYOA incluyen varios métodos como [DIA](#dia-direct-internet-access), túneles GRE y peering privado. Consulte [Creación de Interfaces CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) para detalles de configuración. ### DIA (Direct Internet Access) -Un término estándar de redes para la conectividad proporcionada a través de la internet pública. En DoubleZero, DIA es un tipo de interfaz [CYOA](#cyoa-choose-your-own-adventure) donde los usuarios (validadores, operadores RPC) se conectan a un [DZD](#dzd-doublezero-device) a través de su conexión a internet existente. +Un término estándar de redes para la conectividad proporcionada a través de internet público. En DoubleZero, DIA es un tipo de interfaz [CYOA](#cyoa-choose-your-own-adventure) donde los usuarios (validadores, operadores RPC) se conectan a un [DZD](#dzd-doublezero-device) a través de su conexión a internet existente. ### IBRL (Increase Bandwidth Reduce Latency) -Un modo de conexión que permite a los validadores y nodos RPC conectarse a DoubleZero sin reiniciar sus clientes de blockchain. IBRL utiliza la dirección IP pública existente y establece un túnel superpuesto al [DZD](#dzd-doublezero-device) más cercano. Consulte [Conexión Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instrucciones de configuración. +Un modo de conexión que permite a los validadores y nodos RPC conectarse a DoubleZero sin reiniciar sus clientes de blockchain. IBRL utiliza la dirección IP pública existente y establece un túnel overlay hacia el [DZD](#dzd-doublezero-device) más cercano. Consulte [Conexión Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instrucciones de configuración. ### Multicast Un método de entrega de paquetes de uno a muchos soportado por DoubleZero. El modo multicast tiene dos roles: **publisher** (envía paquetes a través de la red) y **subscriber** (recibe paquetes del publisher). Utilizado por equipos de desarrollo para la distribución eficiente de datos. Consulte [Otra Conexión Multicast](Other%20Multicast%20Connection.md) para detalles de conexión. @@ -62,7 +62,7 @@ Un método de entrega de paquetes de uno a muchos soportado por DoubleZero. El m El servicio daemon de DoubleZero que se ejecuta en los servidores de los usuarios (validadores, nodos RPC). Gestiona la conexión a la red DoubleZero, maneja el establecimiento de túneles y mantiene la conectividad con los [DZDs](#dzd-doublezero-device). Se configura mediante systemd y se controla a través del CLI [`doublezero`](#doublezero-cli). ### doublezero (CLI) -La interfaz de línea de comandos para interactuar con la red DoubleZero. Se utiliza para conectar, gestionar identidades, verificar el estado y operaciones administrativas. Se comunica con el daemon [`doublezerod`](#doublezerod). +La interfaz de línea de comandos para interactuar con la red DoubleZero. Se utiliza para conectarse, gestionar identidades, verificar el estado y operaciones administrativas. Se comunica con el daemon [`doublezerod`](#doublezerod). ### Config Agent Agente de software que se ejecuta en los [DZDs](#dzd-doublezero-device) y gestiona la configuración del dispositivo. Lee la configuración del servicio [Controller](#controller) y aplica los cambios al dispositivo. Consulte [Instalación del Config Agent](contribute-provisioning.md#step-44-install-config-agent) para la configuración. @@ -71,7 +71,7 @@ Agente de software que se ejecuta en los [DZDs](#dzd-doublezero-device) y gestio Agente de software que se ejecuta en los [DZDs](#dzd-doublezero-device) y recopila métricas de rendimiento (latencia, jitter, pérdida de paquetes) y las envía al ledger de DoubleZero. Consulte [Instalación del Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) para la configuración. ### Controller -Un servicio que proporciona configuración a los agentes de los [DZD](#dzd-doublezero-device). El Controller deriva las configuraciones de los dispositivos del estado [onchain](#onchain) en el ledger de DoubleZero. +Un servicio que proporciona configuración a los agentes de los [DZDs](#dzd-doublezero-device). El Controller deriva las configuraciones de los dispositivos a partir del estado [onchain](#onchain) en el ledger de DoubleZero. --- @@ -81,20 +81,20 @@ Un servicio que proporciona configuración a los agentes de los [DZD](#dzd-doubl El estado operativo normal para un enlace. El tráfico fluye a través del enlace y participa en las decisiones de enrutamiento. ### Soft-Drained -Un estado de mantenimiento donde se desalentará el tráfico en un enlace específico. Se utiliza para ventanas de mantenimiento planificado. Puede transicionar a [activated](#activated) o [hard-drained](#hard-drained). +Un estado de mantenimiento donde se desaconseja el tráfico en un enlace específico. Se utiliza para ventanas de mantenimiento con transición gradual. Puede transicionar a [activated](#activated) o [hard-drained](#hard-drained). ### Hard-Drained -Un estado de mantenimiento donde el enlace se retira completamente del servicio. No fluye tráfico a través del enlace. Debe transicionar a [soft-drained](#soft-drained) antes de regresar a [activated](#activated). +Un estado de mantenimiento donde el enlace se retira completamente del servicio. No fluye tráfico a través del enlace. Debe transicionar a [soft-drained](#soft-drained) antes de volver a [activated](#activated). --- ## Organizaciones y Tokens ### DZF (DoubleZero Foundation) -DoubleZero Foundation es una fundación sin miembros constituida como compañía fundacional sin fines de lucro en las Islas Caimán, creada para apoyar el desarrollo, descentralización, seguridad y adopción de la red DoubleZero. +DoubleZero Foundation es una empresa fundacional sin miembros y sin fines de lucro de las Islas Caimán que fue constituida para apoyar el desarrollo, la descentralización, la seguridad y la adopción de la red DoubleZero. ### 2Z Token -El token nativo de la red DoubleZero. Se utiliza para pagar las comisiones de los validadores y se distribuye como recompensas a los [contribuidores](#contributor). Los validadores pueden pagar las comisiones en 2Z a través de un programa de intercambio onchain. Consulte [Intercambio de SOL a 2Z](Swapping-sol-to-2z.md). +El token nativo de la red DoubleZero. Se utiliza para pagar las tarifas de los validadores y se distribuye como recompensas a los [contribuidores](#contributor). Los validadores pueden pagar las tarifas en 2Z a través de un programa de intercambio onchain. Consulte [Intercambio de SOL a 2Z](Swapping-sol-to-2z.md). ### Contributor Un proveedor de infraestructura de red que contribuye ancho de banda y hardware a la red DoubleZero. Los contribuidores operan [DZDs](#dzd-doublezero-device), proporcionan enlaces [WAN](#wan-link) y [DZX](#dzx-link), y reciben incentivos en tokens [2Z](#2z-token) por su contribución. Consulte la [Documentación para Contribuidores](contribute-overview.md) para comenzar. @@ -104,13 +104,13 @@ Un proveedor de infraestructura de red que contribuye ancho de banda y hardware ## Conceptos de Redes ### MTU (Maximum Transmission Unit) -El tamaño máximo de paquete (en bytes) que puede transmitirse a través de un enlace de red. Los enlaces WAN de DoubleZero generalmente utilizan MTU 9000 (jumbo frames) para mayor eficiencia. +El tamaño máximo de paquete (en bytes) que puede transmitirse a través de un enlace de red. Los enlaces WAN de DoubleZero típicamente utilizan MTU 9000 (jumbo frames) para mayor eficiencia. ### VRF (Virtual Routing and Forwarding) -Una tecnología que permite que múltiples tablas de enrutamiento aisladas coexistan en el mismo router físico. Los contribuidores a menudo utilizan un VRF de gestión separado para aislar el tráfico de administración del switch del tráfico de producción. +Una tecnología que permite que múltiples tablas de enrutamiento aisladas existan en el mismo router físico. Los contribuidores frecuentemente utilizan un VRF de gestión separado para aislar el tráfico de administración del switch del tráfico de producción. ### GRE (Generic Routing Encapsulation) -Un protocolo de tunelización que encapsula paquetes de red dentro de paquetes IP. Utilizado por las conexiones [IBRL](#ibrl-increase-bandwidth-reduce-latency) y [CYOA](#cyoa-choose-your-own-adventure) para crear túneles superpuestos entre usuarios y DZDs. +Un protocolo de tunelización que encapsula paquetes de red dentro de paquetes IP. Utilizado por las conexiones [IBRL](#ibrl-increase-bandwidth-reduce-latency) y [CYOA](#cyoa-choose-your-own-adventure) para crear túneles overlay entre usuarios y DZDs. ### BGP (Border Gateway Protocol) El protocolo de enrutamiento utilizado para intercambiar información de enrutamiento entre redes en internet. DoubleZero utiliza BGP internamente con ASN 65342. @@ -119,48 +119,51 @@ El protocolo de enrutamiento utilizado para intercambiar información de enrutam Un identificador único asignado a una red para el enrutamiento BGP. Todos los dispositivos DoubleZero utilizan **ASN 65342** para el proceso BGP interno. ### Loopback Interface -Una interfaz de red virtual en un router/switch utilizada para fines de gestión y enrutamiento. Los DZDs utilizan Loopback255 (VPNv4) y Loopback256 (IPv4) para el enrutamiento interno. +Una interfaz de red virtual en un router/switch utilizada con fines de gestión y enrutamiento. Los DZDs utilizan Loopback255 (VPNv4) y Loopback256 (IPv4) para el enrutamiento interno. ### CIDR (Classless Inter-Domain Routing) -Una notación para especificar rangos de direcciones IP. El formato es `IP/prefix-length` donde la longitud del prefijo indica el tamaño de la red (por ejemplo, `/29` = 8 direcciones, `/24` = 256 direcciones). +Una notación para especificar rangos de direcciones IP. El formato es `IP/longitud-de-prefijo` donde la longitud del prefijo indica el tamaño de la red (por ejemplo, `/29` = 8 direcciones, `/24` = 256 direcciones). ### Jitter Variación en la latencia de los paquetes a lo largo del tiempo. Un jitter bajo es crítico para aplicaciones en tiempo real. ### RTT (Round-Trip Time) -El tiempo que tarda un paquete en viajar desde el origen al destino y regresar. Se utiliza para medir la latencia de red entre dispositivos. +El tiempo que tarda un paquete en viajar desde el origen hasta el destino y de vuelta. Se utiliza para medir la latencia de red entre dispositivos. ### TWAMP (Two-Way Active Measurement Protocol) -Un protocolo para medir métricas de rendimiento de red como la latencia y la pérdida de paquetes. El [Telemetry Agent](#telemetry-agent) utiliza TWAMP para recopilar métricas entre DZDs. +Un protocolo para medir métricas de rendimiento de red como latencia y pérdida de paquetes. El [Telemetry Agent](#telemetry-agent) utiliza TWAMP para recopilar métricas entre DZDs. ### IS-IS (Intermediate System to Intermediate System) -Un protocolo de enrutamiento de estado de enlace utilizado internamente por la red DoubleZero. Las métricas de IS-IS se ajustan durante las operaciones de [drenaje de enlaces](#soft-drained). +Un protocolo de enrutamiento de estado de enlace utilizado internamente por la red DoubleZero. Las métricas de IS-IS se ajustan durante las operaciones de [drenado de enlaces](#soft-drained). --- ## Geolocalización ### Geolocation -Un servicio de DoubleZero que verifica la ubicación física de los dispositivos mediante mediciones de latencia. Las mediciones de [RTT](#rtt-round-trip-time) entre infraestructura de ubicación conocida ([DZDs](#dzd-doublezero-device)) y los dispositivos objetivo proporcionan prueba firmada criptográficamente de que un dispositivo se encuentra dentro de cierta distancia de un punto de referencia. El registro onchain de las mediciones está planificado para una versión futura. Consulte [Geolocalización](geolocation.md) para la documentación de usuario. +Un servicio de DoubleZero que verifica la ubicación física de los dispositivos utilizando mediciones de latencia. Las mediciones de [RTT](#rtt-round-trip-time) entre infraestructura de ubicación conocida ([DZDs](#dzd-doublezero-device)) y dispositivos objetivo proporcionan una prueba firmada criptográficamente de que un dispositivo se encuentra dentro de una cierta distancia de un punto de referencia. El registro onchain de las mediciones está planificado para una versión futura. Consulte [Geolocalización](geolocation.md) para la documentación de usuario. ### geoProbe -Un servidor bare metal que actúa como intermediario para las mediciones de latencia en el sistema de [Geolocalización](#geolocation). Los geoProbes están ubicados a ~1ms de un [DZD](#dzd-doublezero-device), reciben LocationOffsets firmados de los DZDs padre, y miden el [RTT](#rtt-round-trip-time) hacia los dispositivos objetivo mediante [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmado o ICMP echo. Cada geoProbe se registra [onchain](#onchain) y se vincula a uno o más DZDs padre. Consulte [Despliegue de Geoprobe](contribute-geolocation.md) para la documentación de contribuidores. +Un servidor bare metal que actúa como intermediario para las mediciones de latencia en el sistema de [Geolocalización](#geolocation). Los geoProbes están ubicados a ~1ms de un [DZD](#dzd-doublezero-device), reciben LocationOffsets firmados de los DZDs padre y miden el [RTT](#rtt-round-trip-time) hacia los dispositivos objetivo mediante [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmado o ICMP echo. Cada geoProbe se registra [onchain](#onchain) y se vincula a uno o más DZDs padre. Consulte [Despliegue de Geoprobe](contribute-geolocation.md) para la documentación de contribuidores. ### LocationOffset -Una estructura de datos firmada que contiene la ubicación geográfica de un [DZD](#dzd-doublezero-device) (latitud y longitud) y una cadena de relaciones de latencia entre entidades (DZD↔Probe o Probe↔Target). Los LocationOffsets se firman con Ed25519 y se envían vía UDP a través de la cadena de medición. Los offsets compuestos incluyen referencias a mediciones anteriores, creando un rastro auditable. +Una estructura de datos firmada que contiene la ubicación geográfica de un [DZD](#dzd-doublezero-device) (latitud y longitud) y una cadena de relaciones de latencia entre entidades (DZD↔Probe o Probe↔Target). Los LocationOffsets se firman con Ed25519 y se envían mediante UDP a través de la cadena de medición. Los offsets compuestos incluyen referencias a mediciones anteriores, creando un rastro auditable. --- ## Blockchain y Claves ### Onchain -En el contexto de DoubleZero, onchain se refiere a datos y operaciones registrados en el ledger de DoubleZero. A diferencia de las redes tradicionales donde las configuraciones de dispositivos y enlaces residen en sistemas de gestión centralizados, DoubleZero registra los registros de dispositivos, las configuraciones de enlaces y los envíos de telemetría onchain, haciendo que el estado de la red sea transparente y verificable por todos los participantes. +En el contexto de DoubleZero, onchain se refiere a datos y operaciones registrados en el ledger de DoubleZero. A diferencia de las redes tradicionales donde las configuraciones de dispositivos y enlaces residen en sistemas de gestión centralizados, DoubleZero registra los registros de dispositivos, configuraciones de enlaces y envíos de telemetría onchain — haciendo que el estado de la red sea transparente y verificable por todos los participantes. ### Service Key -Un par de claves criptográficas utilizado para autenticar las operaciones del CLI. Esta es su identidad como contribuidor para interactuar con el contrato inteligente de DoubleZero. Se almacena en `~/.config/solana/id.json`. +Un par de claves criptográficas utilizado para autenticar operaciones del CLI. Esta es su identidad de contribuidor para interactuar con el contrato inteligente de DoubleZero. Se almacena en `~/.config/solana/id.json`. ### Metrics Publisher Key -Un par de claves criptográficas utilizado por el [Telemetry Agent](#telemetry-agent) para firmar los envíos de métricas al blockchain. Separado de la service key para aislamiento de seguridad. Se almacena en `~/.config/doublezero/metrics-publisher.json`. +Un par de claves criptográficas utilizado por el [Telemetry Agent](#telemetry-agent) para firmar los envíos de métricas a la blockchain. Separado de la service key para aislamiento de seguridad. Se almacena en `~/.config/doublezero/metrics-publisher.json`. + +### Rewards Manager Key +Un par de claves criptográficas que controla dónde se pagan las recompensas de un contribuidor. Firma los cambios en la lista de billeteras destinatarias pero nunca retiene las recompensas en sí. Se registra contra la [Service Key](#service-key) del contribuidor por la [DZF](#dzf-doublezero-foundation). Consulte [Gestión de Recompensas](contribute-rewards.md). --- diff --git a/docs/glossary.fr.md b/docs/glossary.fr.md index af5c25e..8bf565a 100644 --- a/docs/glossary.fr.md +++ b/docs/glossary.fr.md @@ -11,39 +11,39 @@ Cette page définit la terminologie spécifique à DoubleZero utilisée dans l'e ## Infrastructure réseau ### DZD (DoubleZero Device) -Le matériel physique de commutation réseau qui termine les liens DoubleZero et exécute le logiciel DoubleZero Agent. Les DZDs sont déployés dans les centres de données et fournissent des services de routage, de traitement des paquets et de connectivité utilisateur. Chaque DZD nécessite des [spécifications matérielles](contribute.md#dzd-network-hardware) spécifiques et exécute à la fois le [Config Agent](#config-agent) et le [Telemetry Agent](#telemetry-agent). +Le matériel physique de commutation réseau qui termine les liens DoubleZero et exécute le logiciel DoubleZero Agent. Les DZD sont déployés dans les centres de données et fournissent des services de routage, de traitement de paquets et de connectivité utilisateur. Chaque DZD nécessite des [spécifications matérielles](contribute.md#dzd-network-hardware) précises et exécute à la fois le [Config Agent](#config-agent) et le [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Points d'interconnexion dans le réseau maillé où les liens de différents [contributeurs](#contributeur) sont reliés entre eux. Les DZXs sont situés dans les grandes zones métropolitaines (par ex., NYC, LON, TYO) où se produisent les intersections réseau. Les contributeurs réseau doivent raccorder leurs liens au maillage DoubleZero global au DZX le plus proche. Concept similaire à un point d'échange Internet (IX). +Points d'interconnexion dans le réseau maillé où les liens de différents [contributeurs](#contributor) sont reliés entre eux. Les DZX sont situés dans les grandes métropoles (par ex. NYC, LON, TYO) où se produisent les intersections réseau. Les contributeurs réseau doivent interconnecter leurs liens au maillage DoubleZero plus large au DZX le plus proche. Concept similaire à un point d'échange Internet (IX). -### Lien WAN -Un lien de réseau étendu (Wide Area Network) entre deux [DZDs](#dzd-doublezero-device) opérés par le **même** contributeur. Les liens WAN fournissent la connectivité dorsale au sein de l'infrastructure d'un seul contributeur. +### WAN Link +Un lien de réseau étendu (Wide Area Network) entre deux [DZD](#dzd-doublezero-device) exploités par le **même** contributeur. Les liens WAN fournissent la connectivité dorsale au sein de l'infrastructure d'un seul contributeur. -### Lien DZX -Un lien entre [DZDs](#dzd-doublezero-device) opérés par des contributeurs **différents**, établi au niveau d'un [DZX](#dzx-doublezero-exchange). Les liens DZX nécessitent une acceptation explicite des deux parties. +### DZX Link +Un lien entre des [DZD](#dzd-doublezero-device) exploités par des contributeurs **différents**, établi au niveau d'un [DZX](#dzx-doublezero-exchange). Les liens DZX nécessitent une acceptation explicite des deux parties. -### Préfixe DZ +### DZ Prefix Allocations d'adresses IP au format CIDR attribuées à un [DZD](#dzd-doublezero-device) pour l'adressage du réseau overlay. Spécifié lors de la [création du dispositif](contribute-provisioning.md#step-32-create-your-device-onchain) à l'aide du paramètre `--dz-prefixes`. --- ## Types de dispositifs -### Dispositif Edge +### Edge Device Un [DZD](#dzd-doublezero-device) qui fournit la connectivité utilisateur au réseau DoubleZero. Les dispositifs edge exploitent les interfaces [CYOA](#cyoa-choose-your-own-adventure) pour terminer les utilisateurs (validateurs, opérateurs RPC) et les connecter au réseau. -### Dispositif Transit -Un [DZD](#dzd-doublezero-device) qui fournit la connectivité dorsale au sein du réseau DoubleZero. Les dispositifs transit acheminent le trafic entre les DZDs mais ne terminent pas directement les connexions utilisateur. +### Transit Device +Un [DZD](#dzd-doublezero-device) qui fournit la connectivité dorsale au sein du réseau DoubleZero. Les dispositifs transit acheminent le trafic entre les DZD mais ne terminent pas directement les connexions utilisateur. -### Dispositif Hybride -Un [DZD](#dzd-doublezero-device) qui combine les fonctionnalités [edge](#dispositif-edge) et [transit](#dispositif-transit), fournissant à la fois la connectivité utilisateur et le routage dorsal. +### Hybrid Device +Un [DZD](#dzd-doublezero-device) qui combine les fonctionnalités [edge](#edge-device) et [transit](#transit-device), fournissant à la fois la connectivité utilisateur et le routage dorsal. --- ## Connectivité ### CYOA (Choose Your Own Adventure) -Types d'interfaces qui permettent aux [contributeurs](#contributeur) d'enregistrer des options de connectivité pour que les utilisateurs se connectent au réseau DoubleZero. Les interfaces CYOA incluent diverses méthodes comme le [DIA](#dia-direct-internet-access), les tunnels GRE et le peering privé. Voir [Création des interfaces CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) pour les détails de configuration. +Types d'interfaces qui permettent aux [contributeurs](#contributor) d'enregistrer des options de connectivité pour que les utilisateurs se connectent au réseau DoubleZero. Les interfaces CYOA incluent diverses méthodes comme le [DIA](#dia-direct-internet-access), les tunnels GRE et le peering privé. Voir [Création des interfaces CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) pour les détails de configuration. ### DIA (Direct Internet Access) Un terme réseau standard désignant la connectivité fournie via l'internet public. Dans DoubleZero, le DIA est un type d'interface [CYOA](#cyoa-choose-your-own-adventure) où les utilisateurs (validateurs, opérateurs RPC) se connectent à un [DZD](#dzd-doublezero-device) via leur connexion internet existante. @@ -52,39 +52,39 @@ Un terme réseau standard désignant la connectivité fournie via l'internet pub Un mode de connexion qui permet aux validateurs et aux nœuds RPC de se connecter à DoubleZero sans redémarrer leurs clients blockchain. IBRL utilise l'adresse IP publique existante et établit un tunnel overlay vers le [DZD](#dzd-doublezero-device) le plus proche. Voir [Connexion Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) pour les instructions de configuration. ### Multicast -Une méthode de livraison de paquets un-vers-plusieurs prise en charge par DoubleZero. Le mode multicast a deux rôles : **éditeur** (envoie les paquets à travers le réseau) et **abonné** (reçoit les paquets de l'éditeur). Utilisé par les équipes de développement pour une distribution efficace des données. Voir [Autre connexion Multicast](Other%20Multicast%20Connection.md) pour les détails de connexion. +Une méthode de livraison de paquets de un vers plusieurs supportée par DoubleZero. Le mode multicast comporte deux rôles : **éditeur** (envoie des paquets à travers le réseau) et **abonné** (reçoit des paquets de l'éditeur). Utilisé par les équipes de développement pour une distribution efficace des données. Voir [Autre connexion Multicast](Other%20Multicast%20Connection.md) pour les détails de connexion. --- ## Composants logiciels ### doublezerod -Le service daemon DoubleZero qui s'exécute sur les serveurs utilisateur (validateurs, nœuds RPC). Il gère la connexion au réseau DoubleZero, assure l'établissement des tunnels et maintient la connectivité vers les [DZDs](#dzd-doublezero-device). Configuré via systemd et contrôlé par le CLI [`doublezero`](#doublezero-cli). +Le service daemon DoubleZero qui s'exécute sur les serveurs des utilisateurs (validateurs, nœuds RPC). Il gère la connexion au réseau DoubleZero, assure l'établissement des tunnels et maintient la connectivité vers les [DZD](#dzd-doublezero-device). Configuré via systemd et contrôlé par la CLI [`doublezero`](#doublezero-cli). ### doublezero (CLI) -L'interface en ligne de commande pour interagir avec le réseau DoubleZero. Utilisée pour se connecter, gérer les identités, vérifier l'état et effectuer des opérations d'administration. Communique avec le daemon [`doublezerod`](#doublezerod). +L'interface en ligne de commande pour interagir avec le réseau DoubleZero. Utilisée pour se connecter, gérer les identités, vérifier l'état et effectuer des opérations administratives. Communique avec le daemon [`doublezerod`](#doublezerod). ### Config Agent -Agent logiciel s'exécutant sur les [DZDs](#dzd-doublezero-device) qui gère la configuration du dispositif. Lit la configuration depuis le service [Controller](#controller) et applique les modifications au dispositif. Voir [Installation du Config Agent](contribute-provisioning.md#step-44-install-config-agent) pour la mise en place. +Agent logiciel s'exécutant sur les [DZD](#dzd-doublezero-device) qui gère la configuration des dispositifs. Lit la configuration depuis le service [Controller](#controller) et applique les modifications au dispositif. Voir [Installation du Config Agent](contribute-provisioning.md#step-44-install-config-agent) pour la mise en place. ### Telemetry Agent -Agent logiciel s'exécutant sur les [DZDs](#dzd-doublezero-device) qui collecte les métriques de performance (latence, gigue, perte de paquets) et les soumet au registre DoubleZero. Voir [Installation du Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) pour la mise en place. +Agent logiciel s'exécutant sur les [DZD](#dzd-doublezero-device) qui collecte les métriques de performance (latence, gigue, perte de paquets) et les soumet au registre DoubleZero. Voir [Installation du Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) pour la mise en place. ### Controller -Un service qui fournit la configuration aux agents [DZD](#dzd-doublezero-device). Le Controller dérive les configurations des dispositifs à partir de l'état [onchain](#onchain) sur le registre DoubleZero. +Un service qui fournit la configuration aux agents des [DZD](#dzd-doublezero-device). Le Controller dérive les configurations des dispositifs à partir de l'état [onchain](#onchain) sur le registre DoubleZero. --- ## États des liens -### Activé +### Activated L'état opérationnel normal d'un lien. Le trafic circule à travers le lien et celui-ci participe aux décisions de routage. -### Drainage progressif (Soft-Drained) -Un état de maintenance où le trafic sera découragé sur un lien spécifique. Utilisé pour des fenêtres de maintenance gracieuses. Peut transiter vers l'état [activé](#activé) ou [drainage complet](#drainage-complet-hard-drained). +### Soft-Drained +Un état de maintenance où le trafic sera découragé sur un lien spécifique. Utilisé pour des fenêtres de maintenance progressives. Peut transiter vers [activated](#activated) ou [hard-drained](#hard-drained). -### Drainage complet (Hard-Drained) -Un état de maintenance où le lien est complètement retiré du service. Aucun trafic ne circule à travers le lien. Doit transiter vers l'état [drainage progressif](#drainage-progressif-soft-drained) avant de revenir à l'état [activé](#activé). +### Hard-Drained +Un état de maintenance où le lien est complètement retiré du service. Aucun trafic ne circule à travers le lien. Doit transiter vers [soft-drained](#soft-drained) avant de revenir à [activated](#activated). --- @@ -93,24 +93,24 @@ Un état de maintenance où le lien est complètement retiré du service. Aucun ### DZF (DoubleZero Foundation) La DoubleZero Foundation est une société-fondation sans membres à but non lucratif des îles Caïmans, créée pour soutenir le développement, la décentralisation, la sécurité et l'adoption du réseau DoubleZero. -### Jeton 2Z -Le jeton natif du réseau DoubleZero. Utilisé pour payer les frais des validateurs et distribué comme récompenses aux [contributeurs](#contributeur). Les validateurs peuvent payer les frais en 2Z via un programme d'échange onchain. Voir [Échange de SOL en 2Z](Swapping-sol-to-2z.md). +### 2Z Token +Le jeton natif du réseau DoubleZero. Utilisé pour le paiement des frais de validateur et distribué en récompense aux [contributeurs](#contributor). Les validateurs peuvent payer les frais en 2Z via un programme d'échange onchain. Voir [Échanger des SOL en 2Z](Swapping-sol-to-2z.md). -### Contributeur -Un fournisseur d'infrastructure réseau qui contribue en bande passante et en matériel au réseau DoubleZero. Les contributeurs opèrent des [DZDs](#dzd-doublezero-device), fournissent des liens [WAN](#lien-wan) et [DZX](#lien-dzx), et reçoivent des incitations en jetons [2Z](#jeton-2z) pour leur contribution. Voir la [Documentation des contributeurs](contribute-overview.md) pour commencer. +### Contributor +Un fournisseur d'infrastructure réseau qui contribue en bande passante et matériel au réseau DoubleZero. Les contributeurs exploitent des [DZD](#dzd-doublezero-device), fournissent des liens [WAN](#wan-link) et [DZX](#dzx-link), et reçoivent des incitations en jetons [2Z](#2z-token) pour leur contribution. Voir la [Documentation des contributeurs](contribute-overview.md) pour commencer. --- ## Concepts réseau ### MTU (Maximum Transmission Unit) -La plus grande taille de paquet (en octets) pouvant être transmise sur un lien réseau. Les liens WAN DoubleZero utilisent généralement un MTU de 9000 (trames jumbo) pour plus d'efficacité. +La taille maximale de paquet (en octets) pouvant être transmise sur un lien réseau. Les liens WAN DoubleZero utilisent généralement un MTU de 9000 (trames jumbo) pour plus d'efficacité. ### VRF (Virtual Routing and Forwarding) Une technologie qui permet à plusieurs tables de routage isolées de coexister sur le même routeur physique. Les contributeurs utilisent souvent un VRF de gestion séparé pour isoler le trafic de gestion du commutateur du trafic de production. ### GRE (Generic Routing Encapsulation) -Un protocole de tunnelisation qui encapsule les paquets réseau à l'intérieur de paquets IP. Utilisé par les connexions [IBRL](#ibrl-increase-bandwidth-reduce-latency) et [CYOA](#cyoa-choose-your-own-adventure) pour créer des tunnels overlay entre les utilisateurs et les DZDs. +Un protocole de tunnelisation qui encapsule les paquets réseau dans des paquets IP. Utilisé par les connexions [IBRL](#ibrl-increase-bandwidth-reduce-latency) et [CYOA](#cyoa-choose-your-own-adventure) pour créer des tunnels overlay entre les utilisateurs et les DZD. ### BGP (Border Gateway Protocol) Le protocole de routage utilisé pour l'échange d'informations de routage entre les réseaux sur Internet. DoubleZero utilise BGP en interne avec l'ASN 65342. @@ -118,36 +118,36 @@ Le protocole de routage utilisé pour l'échange d'informations de routage entre ### ASN (Autonomous System Number) Un identifiant unique attribué à un réseau pour le routage BGP. Tous les dispositifs DoubleZero utilisent l'**ASN 65342** pour le processus BGP interne. -### Interface Loopback -Une interface réseau virtuelle sur un routeur/commutateur utilisée à des fins de gestion et de routage. Les DZDs utilisent Loopback255 (VPNv4) et Loopback256 (IPv4) pour le routage interne. +### Loopback Interface +Une interface réseau virtuelle sur un routeur/commutateur utilisée à des fins de gestion et de routage. Les DZD utilisent Loopback255 (VPNv4) et Loopback256 (IPv4) pour le routage interne. ### CIDR (Classless Inter-Domain Routing) Une notation pour spécifier les plages d'adresses IP. Le format est `IP/longueur-de-préfixe` où la longueur du préfixe indique la taille du réseau (par ex., `/29` = 8 adresses, `/24` = 256 adresses). -### Gigue (Jitter) +### Jitter Variation de la latence des paquets au fil du temps. Une faible gigue est essentielle pour les applications en temps réel. ### RTT (Round-Trip Time) Le temps nécessaire pour qu'un paquet voyage de la source à la destination et revienne. Utilisé pour mesurer la latence réseau entre les dispositifs. ### TWAMP (Two-Way Active Measurement Protocol) -Un protocole pour mesurer les métriques de performance réseau comme la latence et la perte de paquets. Le [Telemetry Agent](#telemetry-agent) utilise TWAMP pour collecter les métriques entre les DZDs. +Un protocole de mesure des métriques de performance réseau telles que la latence et la perte de paquets. Le [Telemetry Agent](#telemetry-agent) utilise TWAMP pour collecter les métriques entre les DZD. ### IS-IS (Intermediate System to Intermediate System) -Un protocole de routage à état de lien utilisé en interne par le réseau DoubleZero. Les métriques IS-IS sont ajustées lors des opérations de [drainage de lien](#drainage-progressif-soft-drained). +Un protocole de routage à état de lien utilisé en interne par le réseau DoubleZero. Les métriques IS-IS sont ajustées lors des opérations de [drainage de lien](#soft-drained). --- ## Géolocalisation -### Géolocalisation -Un service DoubleZero qui vérifie l'emplacement physique des dispositifs à l'aide de mesures de latence. Les mesures de [RTT](#rtt-round-trip-time) entre l'infrastructure à emplacement connu ([DZDs](#dzd-doublezero-device)) et les dispositifs cibles fournissent une preuve signée cryptographiquement qu'un dispositif se trouve à une certaine distance d'un point de référence. L'enregistrement onchain des mesures est prévu pour une version future. Voir [Géolocalisation](geolocation.md) pour la documentation utilisateur. +### Geolocation +Un service DoubleZero qui vérifie l'emplacement physique des dispositifs à l'aide de mesures de latence. Les mesures de [RTT](#rtt-round-trip-time) entre l'infrastructure à emplacement connu ([DZD](#dzd-doublezero-device)) et les dispositifs cibles fournissent une preuve signée cryptographiquement qu'un dispositif se trouve à une certaine distance d'un point de référence. L'enregistrement onchain des mesures est prévu pour une version future. Voir [Géolocalisation](geolocation.md) pour la documentation utilisateur. ### geoProbe -Un serveur bare metal qui agit comme intermédiaire pour les mesures de latence dans le système de [Géolocalisation](#géolocalisation). Les geoProbes sont situés à ~1ms d'un [DZD](#dzd-doublezero-device), reçoivent des LocationOffsets signés des DZDs parents, et mesurent le [RTT](#rtt-round-trip-time) vers les dispositifs cibles via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP signé, ou écho ICMP. Chaque geoProbe est enregistré [onchain](#onchain) et lié à un ou plusieurs DZDs parents. Voir [Déploiement des Geoprobes](contribute-geolocation.md) pour la documentation des contributeurs. +Un serveur bare metal qui agit comme intermédiaire pour les mesures de latence dans le système de [Géolocalisation](#geolocation). Les geoProbes sont situés à ~1ms d'un [DZD](#dzd-doublezero-device), reçoivent des LocationOffsets signés des DZD parents et mesurent le [RTT](#rtt-round-trip-time) vers les dispositifs cibles via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP signé ou écho ICMP. Chaque geoProbe est enregistré [onchain](#onchain) et lié à un ou plusieurs DZD parents. Voir [Déploiement des Geoprobes](contribute-geolocation.md) pour la documentation des contributeurs. ### LocationOffset -Une structure de données signée contenant la position géographique d'un [DZD](#dzd-doublezero-device) (latitude et longitude) et une chaîne de relations de latence entre entités (DZD↔Probe ou Probe↔Cible). Les LocationOffsets sont signés avec Ed25519 et envoyés via UDP à travers la chaîne de mesure. Les offsets composites incluent des références aux mesures précédentes, créant une piste d'audit vérifiable. +Une structure de données signée contenant l'emplacement géographique (latitude et longitude) d'un [DZD](#dzd-doublezero-device) et une chaîne de relations de latence entre entités (DZD↔Probe ou Probe↔Cible). Les LocationOffsets sont signés avec Ed25519 et envoyés via UDP à travers la chaîne de mesure. Les offsets composites incluent des références aux mesures précédentes, créant une piste d'audit vérifiable. --- @@ -156,11 +156,14 @@ Une structure de données signée contenant la position géographique d'un [DZD] ### Onchain Dans le contexte DoubleZero, onchain fait référence aux données et opérations enregistrées sur le registre DoubleZero. Contrairement aux réseaux traditionnels où les configurations des dispositifs et des liens résident dans des systèmes de gestion centralisés, DoubleZero enregistre les inscriptions de dispositifs, les configurations de liens et les soumissions de télémétrie onchain — rendant l'état du réseau transparent et vérifiable par tous les participants. -### Clé de service (Service Key) -Une paire de clés cryptographiques utilisée pour authentifier les opérations CLI. C'est votre identité de contributeur pour interagir avec le contrat intelligent DoubleZero. Stockée dans `~/.config/solana/id.json`. +### Service Key +Une paire de clés cryptographiques utilisée pour authentifier les opérations CLI. Il s'agit de votre identité de contributeur pour interagir avec le contrat intelligent DoubleZero. Stockée à `~/.config/solana/id.json`. -### Clé d'éditeur de métriques (Metrics Publisher Key) -Une paire de clés cryptographiques utilisée par le [Telemetry Agent](#telemetry-agent) pour signer les soumissions de métriques sur la blockchain. Séparée de la clé de service pour l'isolation de sécurité. Stockée dans `~/.config/doublezero/metrics-publisher.json`. +### Metrics Publisher Key +Une paire de clés cryptographiques utilisée par le [Telemetry Agent](#telemetry-agent) pour signer les soumissions de métriques à la blockchain. Séparée de la clé de service pour l'isolation de sécurité. Stockée à `~/.config/doublezero/metrics-publisher.json`. + +### Rewards Manager Key +Une paire de clés cryptographiques qui contrôle où les récompenses d'un contributeur sont versées. Elle signe les modifications de la liste des portefeuilles destinataires mais ne détient jamais elle-même les récompenses. Enregistrée contre la [Service Key](#service-key) du contributeur par la [DZF](#dzf-doublezero-foundation). Voir [Gestion des récompenses](contribute-rewards.md). --- @@ -169,5 +172,5 @@ Une paire de clés cryptographiques utilisée par le [Telemetry Agent](#telemetr ### EOS (Extensible Operating System) Le système d'exploitation réseau d'Arista qui s'exécute sur les commutateurs DZD. Les contributeurs installent le [Config Agent](#config-agent) et le [Telemetry Agent](#telemetry-agent) en tant qu'extensions EOS. -### Extension EOS +### EOS Extension Un paquet logiciel pouvant être installé sur les commutateurs Arista EOS. Les agents DZ sont distribués sous forme de fichiers `.rpm` et installés via la commande `extension`. \ No newline at end of file diff --git a/docs/glossary.it.md b/docs/glossary.it.md index 945eae1..0c9ff39 100644 --- a/docs/glossary.it.md +++ b/docs/glossary.it.md @@ -11,16 +11,16 @@ Questa pagina definisce la terminologia specifica di DoubleZero utilizzata in tu ## Infrastruttura di Rete ### DZD (DoubleZero Device) -L'hardware fisico di switching di rete che termina i link DoubleZero ed esegue il software DoubleZero Agent. I DZD vengono distribuiti nei data center e forniscono servizi di routing, elaborazione dei pacchetti e connettività utente. Ogni DZD richiede [specifiche hardware](contribute.md#dzd-network-hardware) specifiche ed esegue sia il [Config Agent](#config-agent) che il [Telemetry Agent](#telemetry-agent). +L'hardware fisico di switching di rete che termina i collegamenti DoubleZero ed esegue il software DoubleZero Agent. I DZD sono distribuiti nei data center e forniscono servizi di routing, elaborazione dei pacchetti e connettività utente. Ogni DZD richiede [specifiche hardware](contribute.md#dzd-network-hardware) specifiche ed esegue sia il [Config Agent](#config-agent) che il [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Punti di interconnessione nella rete mesh dove i link di diversi [contributori](#contributor) vengono collegati tra loro. I DZX si trovano nelle principali aree metropolitane (ad es. NYC, LON, TYO) dove si verificano le intersezioni di rete. I contributori di rete devono effettuare il cross-connect dei loro link nella più ampia mesh DoubleZero presso il DZX più vicino. Concetto simile a un Internet Exchange (IX). +Punti di interconnessione nella rete mesh in cui vengono collegati i link di diversi [contributor](#contributor). I DZX si trovano nelle principali aree metropolitane (ad es. NYC, LON, TYO) dove si verificano le intersezioni di rete. I contributor della rete devono effettuare il cross-connect dei propri link nella mesh DoubleZero più ampia presso il DZX più vicino. Concetto simile a un Internet Exchange (IX). ### WAN Link -Un link Wide Area Network tra due [DZD](#dzd-doublezero-device) gestiti dallo **stesso** contributore. I WAN link forniscono connettività backbone all'interno dell'infrastruttura di un singolo contributore. +Un collegamento Wide Area Network tra due [DZD](#dzd-doublezero-device) gestiti dallo **stesso** contributor. I WAN link forniscono connettività backbone all'interno dell'infrastruttura di un singolo contributor. ### DZX Link -Un link tra [DZD](#dzd-doublezero-device) gestiti da contributori **diversi**, stabilito presso un [DZX](#dzx-doublezero-exchange). I DZX link richiedono l'accettazione esplicita da parte di entrambe le parti. +Un collegamento tra [DZD](#dzd-doublezero-device) gestiti da contributor **diversi**, stabilito presso un [DZX](#dzx-doublezero-exchange). I DZX link richiedono l'accettazione esplicita da entrambe le parti. ### DZ Prefix Allocazioni di indirizzi IP in formato CIDR assegnate a un [DZD](#dzd-doublezero-device) per l'indirizzamento della rete overlay. Specificati durante la [creazione del dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) utilizzando il parametro `--dz-prefixes`. @@ -30,29 +30,29 @@ Allocazioni di indirizzi IP in formato CIDR assegnate a un [DZD](#dzd-doublezero ## Tipi di Dispositivo ### Edge Device -Un [DZD](#dzd-doublezero-device) che fornisce connettività utente alla rete DoubleZero. I dispositivi edge sfruttano le interfacce [CYOA](#cyoa-choose-your-own-adventure) per terminare gli utenti (validatori, operatori RPC) e collegarli alla rete. +Un [DZD](#dzd-doublezero-device) che fornisce connettività utente alla rete DoubleZero. Gli edge device sfruttano le interfacce [CYOA](#cyoa-choose-your-own-adventure) per terminare gli utenti (validatori, operatori RPC) e collegarli alla rete. ### Transit Device -Un [DZD](#dzd-doublezero-device) che fornisce connettività backbone all'interno della rete DoubleZero. I dispositivi transit spostano il traffico tra i DZD ma non terminano direttamente le connessioni utente. +Un [DZD](#dzd-doublezero-device) che fornisce connettività backbone all'interno della rete DoubleZero. I transit device trasferiscono il traffico tra i DZD ma non terminano direttamente le connessioni utente. ### Hybrid Device -Un [DZD](#dzd-doublezero-device) che combina le funzionalità sia [edge](#edge-device) che [transit](#transit-device), fornendo sia connettività utente che routing backbone. +Un [DZD](#dzd-doublezero-device) che combina le funzionalità sia di [edge](#edge-device) che di [transit](#transit-device), fornendo sia connettività utente che routing backbone. --- ## Connettività ### CYOA (Choose Your Own Adventure) -Tipi di interfaccia che consentono ai [contributori](#contributor) di registrare opzioni di connettività per permettere agli utenti di connettersi alla rete DoubleZero. Le interfacce CYOA includono vari metodi come [DIA](#dia-direct-internet-access), tunnel GRE e peering privato. Consulta [Creazione delle Interfacce CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) per i dettagli di configurazione. +Tipi di interfaccia che consentono ai [contributor](#contributor) di registrare opzioni di connettività per gli utenti che si collegano alla rete DoubleZero. Le interfacce CYOA includono vari metodi come [DIA](#dia-direct-internet-access), tunnel GRE e peering privato. Consulta [Creazione delle interfacce CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) per i dettagli di configurazione. ### DIA (Direct Internet Access) -Un termine di networking standard per la connettività fornita tramite internet pubblico. In DoubleZero, DIA è un tipo di interfaccia [CYOA](#cyoa-choose-your-own-adventure) in cui gli utenti (validatori, operatori RPC) si connettono a un [DZD](#dzd-doublezero-device) tramite la loro connessione internet esistente. +Un termine di networking standard per la connettività fornita tramite Internet pubblica. In DoubleZero, DIA è un tipo di interfaccia [CYOA](#cyoa-choose-your-own-adventure) in cui gli utenti (validatori, operatori RPC) si connettono a un [DZD](#dzd-doublezero-device) tramite la propria connessione Internet esistente. ### IBRL (Increase Bandwidth Reduce Latency) -Una modalità di connessione che consente a validatori e nodi RPC di connettersi a DoubleZero senza riavviare i loro client blockchain. IBRL utilizza l'indirizzo IP pubblico esistente e stabilisce un tunnel overlay verso il [DZD](#dzd-doublezero-device) più vicino. Consulta [Connessione Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) per le istruzioni di configurazione. +Una modalità di connessione che consente a validatori e nodi RPC di connettersi a DoubleZero senza riavviare i propri client blockchain. IBRL utilizza l'indirizzo IP pubblico esistente e stabilisce un tunnel overlay verso il [DZD](#dzd-doublezero-device) più vicino. Consulta [Connessione Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) per le istruzioni di configurazione. ### Multicast -Un metodo di consegna dei pacchetti uno-a-molti supportato da DoubleZero. La modalità multicast ha due ruoli: **publisher** (invia pacchetti attraverso la rete) e **subscriber** (riceve pacchetti dal publisher). Utilizzato dai team di sviluppo per la distribuzione efficiente dei dati. Consulta [Altra Connessione Multicast](Other%20Multicast%20Connection.md) per i dettagli di connessione. +Un metodo di consegna dei pacchetti uno-a-molti supportato da DoubleZero. La modalità multicast prevede due ruoli: **publisher** (invia pacchetti attraverso la rete) e **subscriber** (riceve pacchetti dal publisher). Utilizzato dai team di sviluppo per la distribuzione efficiente dei dati. Consulta [Altra connessione Multicast](Other%20Multicast%20Connection.md) per i dettagli di connessione. --- @@ -71,49 +71,49 @@ Agente software in esecuzione sui [DZD](#dzd-doublezero-device) che gestisce la Agente software in esecuzione sui [DZD](#dzd-doublezero-device) che raccoglie metriche di prestazione (latenza, jitter, perdita di pacchetti) e le invia al ledger DoubleZero. Consulta [Installazione del Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) per la configurazione. ### Controller -Un servizio che fornisce la configurazione agli agenti [DZD](#dzd-doublezero-device). Il Controller deriva le configurazioni dei dispositivi dallo stato [onchain](#onchain) sul ledger DoubleZero. +Un servizio che fornisce la configurazione agli agenti dei [DZD](#dzd-doublezero-device). Il Controller deriva le configurazioni dei dispositivi dallo stato [onchain](#onchain) sul ledger DoubleZero. --- ## Stati dei Link ### Activated -Lo stato operativo normale di un link. Il traffico fluisce attraverso il link e quest'ultimo partecipa alle decisioni di routing. +Lo stato operativo normale per un link. Il traffico fluisce attraverso il link e questo partecipa alle decisioni di routing. ### Soft-Drained -Uno stato di manutenzione in cui il traffico viene scoraggiato su un link specifico. Utilizzato per finestre di manutenzione graduali. Può transitare verso [activated](#activated) o [hard-drained](#hard-drained). +Uno stato di manutenzione in cui il traffico viene disincentivato su un link specifico. Utilizzato per finestre di manutenzione graduali. Può passare allo stato [activated](#activated) o [hard-drained](#hard-drained). ### Hard-Drained -Uno stato di manutenzione in cui il link viene completamente rimosso dal servizio. Nessun traffico fluisce attraverso il link. Deve transitare verso [soft-drained](#soft-drained) prima di tornare ad [activated](#activated). +Uno stato di manutenzione in cui il link è completamente rimosso dal servizio. Nessun traffico fluisce attraverso il link. Deve passare allo stato [soft-drained](#soft-drained) prima di tornare ad [activated](#activated). --- ## Organizzazioni e Token ### DZF (DoubleZero Foundation) -La DoubleZero Foundation è una fondazione senza membri costituita come società delle Isole Cayman, creata per supportare lo sviluppo, la decentralizzazione, la sicurezza e l'adozione della rete DoubleZero. +DoubleZero Foundation è una fondazione senza scopo di lucro e senza membri, costituita come foundation company nelle Isole Cayman, creata per supportare lo sviluppo, la decentralizzazione, la sicurezza e l'adozione della rete DoubleZero. ### 2Z Token -Il token nativo della rete DoubleZero. Utilizzato per il pagamento delle commissioni dei validatori e distribuito come ricompensa ai [contributori](#contributor). I validatori possono pagare le commissioni in 2Z tramite un programma di swap onchain. Consulta [Scambio di SOL in 2Z](Swapping-sol-to-2z.md). +Il token nativo della rete DoubleZero. Utilizzato per il pagamento delle commissioni dei validatori e distribuito come ricompense ai [contributor](#contributor). I validatori possono pagare le commissioni in 2Z tramite un programma di swap onchain. Consulta [Swap da SOL a 2Z](Swapping-sol-to-2z.md). ### Contributor -Un fornitore di infrastruttura di rete che contribuisce con banda e hardware alla rete DoubleZero. I contributori gestiscono [DZD](#dzd-doublezero-device), forniscono link [WAN](#wan-link) e [DZX](#dzx-link), e ricevono incentivi in token [2Z](#2z-token) per il loro contributo. Consulta la [Documentazione per i Contributori](contribute-overview.md) per iniziare. +Un fornitore di infrastruttura di rete che contribuisce con larghezza di banda e hardware alla rete DoubleZero. I contributor gestiscono i [DZD](#dzd-doublezero-device), forniscono link [WAN](#wan-link) e [DZX](#dzx-link) e ricevono incentivi in token [2Z](#2z-token) per il loro contributo. Consulta la [Documentazione per i Contributor](contribute-overview.md) per iniziare. --- -## Concetti di Networking +## Concetti di Rete ### MTU (Maximum Transmission Unit) -La dimensione massima del pacchetto (in byte) che può essere trasmessa su un link di rete. I WAN link di DoubleZero utilizzano tipicamente MTU 9000 (jumbo frame) per efficienza. +La dimensione massima del pacchetto (in byte) che può essere trasmessa su un collegamento di rete. I WAN link di DoubleZero utilizzano tipicamente MTU 9000 (jumbo frame) per efficienza. ### VRF (Virtual Routing and Forwarding) -Una tecnologia che consente a più tabelle di routing isolate di coesistere sullo stesso router fisico. I contributori spesso utilizzano un VRF di gestione separato per isolare il traffico di gestione dello switch dal traffico di produzione. +Una tecnologia che consente a più tabelle di routing isolate di coesistere sullo stesso router fisico. I contributor spesso utilizzano un VRF di gestione separato per isolare il traffico di gestione dello switch dal traffico di produzione. ### GRE (Generic Routing Encapsulation) -Un protocollo di tunneling che incapsula pacchetti di rete all'interno di pacchetti IP. Utilizzato dalle connessioni [IBRL](#ibrl-increase-bandwidth-reduce-latency) e [CYOA](#cyoa-choose-your-own-adventure) per creare tunnel overlay tra utenti e DZD. +Un protocollo di tunneling che incapsula i pacchetti di rete all'interno di pacchetti IP. Utilizzato dalle connessioni [IBRL](#ibrl-increase-bandwidth-reduce-latency) e [CYOA](#cyoa-choose-your-own-adventure) per creare tunnel overlay tra utenti e DZD. ### BGP (Border Gateway Protocol) -Il protocollo di routing utilizzato per lo scambio di informazioni di routing tra reti su internet. DoubleZero utilizza BGP internamente con ASN 65342. +Il protocollo di routing utilizzato per lo scambio di informazioni di routing tra reti su Internet. DoubleZero utilizza BGP internamente con ASN 65342. ### ASN (Autonomous System Number) Un identificatore univoco assegnato a una rete per il routing BGP. Tutti i dispositivi DoubleZero utilizzano **ASN 65342** per il processo BGP interno. @@ -122,16 +122,16 @@ Un identificatore univoco assegnato a una rete per il routing BGP. Tutti i dispo Un'interfaccia di rete virtuale su un router/switch utilizzata per scopi di gestione e routing. I DZD utilizzano Loopback255 (VPNv4) e Loopback256 (IPv4) per il routing interno. ### CIDR (Classless Inter-Domain Routing) -Una notazione per specificare intervalli di indirizzi IP. Il formato è `IP/prefix-length` dove la lunghezza del prefisso indica la dimensione della rete (ad es. `/29` = 8 indirizzi, `/24` = 256 indirizzi). +Una notazione per specificare intervalli di indirizzi IP. Il formato è `IP/lunghezza-prefisso` dove la lunghezza del prefisso indica la dimensione della rete (ad es. `/29` = 8 indirizzi, `/24` = 256 indirizzi). ### Jitter -Variazione della latenza dei pacchetti nel tempo. Un basso jitter è fondamentale per le applicazioni in tempo reale. +Variazione nella latenza dei pacchetti nel tempo. Un jitter basso è fondamentale per le applicazioni in tempo reale. ### RTT (Round-Trip Time) -Il tempo necessario a un pacchetto per viaggiare dalla sorgente alla destinazione e ritorno. Utilizzato per misurare la latenza di rete tra i dispositivi. +Il tempo impiegato da un pacchetto per viaggiare dalla sorgente alla destinazione e tornare indietro. Utilizzato per misurare la latenza di rete tra i dispositivi. ### TWAMP (Two-Way Active Measurement Protocol) -Un protocollo per la misurazione delle metriche di prestazione della rete come latenza e perdita di pacchetti. Il [Telemetry Agent](#telemetry-agent) utilizza TWAMP per raccogliere metriche tra i DZD. +Un protocollo per misurare le metriche di prestazione della rete come latenza e perdita di pacchetti. Il [Telemetry Agent](#telemetry-agent) utilizza TWAMP per raccogliere metriche tra i DZD. ### IS-IS (Intermediate System to Intermediate System) Un protocollo di routing link-state utilizzato internamente dalla rete DoubleZero. Le metriche IS-IS vengono regolate durante le operazioni di [draining dei link](#soft-drained). @@ -140,34 +140,37 @@ Un protocollo di routing link-state utilizzato internamente dalla rete DoubleZer ## Geolocalizzazione -### Geolocation +### Geolocalizzazione Un servizio DoubleZero che verifica la posizione fisica dei dispositivi utilizzando misurazioni di latenza. Le misurazioni [RTT](#rtt-round-trip-time) tra infrastrutture a posizione nota ([DZD](#dzd-doublezero-device)) e dispositivi target forniscono una prova firmata crittograficamente che un dispositivo si trova entro una certa distanza da un punto di riferimento. La registrazione onchain delle misurazioni è prevista per una versione futura. Consulta [Geolocalizzazione](geolocation.md) per la documentazione utente. ### geoProbe -Un server bare metal che funge da intermediario per le misurazioni di latenza nel sistema di [Geolocalizzazione](#geolocation). I geoProbe sono situati entro ~1ms da un [DZD](#dzd-doublezero-device), ricevono LocationOffset firmati dai DZD parent e misurano l'[RTT](#rtt-round-trip-time) verso i dispositivi target tramite [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmato o ICMP echo. Ogni geoProbe è registrato [onchain](#onchain) e collegato a uno o più DZD parent. Consulta [Distribuzione dei Geoprobe](contribute-geolocation.md) per la documentazione per i contributori. +Un server bare metal che funge da intermediario per le misurazioni di latenza nel sistema di [Geolocalizzazione](#geolocalizzazione). I geoProbe si trovano entro ~1ms da un [DZD](#dzd-doublezero-device), ricevono LocationOffset firmati dai DZD parent e misurano l'[RTT](#rtt-round-trip-time) verso i dispositivi target tramite [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmato o ICMP echo. Ogni geoProbe è registrato [onchain](#onchain) e collegato a uno o più DZD parent. Consulta [Deployment dei Geoprobe](contribute-geolocation.md) per la documentazione dei contributor. ### LocationOffset -Una struttura dati firmata contenente la posizione geografica (latitudine e longitudine) di un [DZD](#dzd-doublezero-device) e una catena di relazioni di latenza tra entità (DZD↔Probe o Probe↔Target). I LocationOffset sono firmati con Ed25519 e inviati tramite UDP attraverso la catena di misurazione. Gli offset compositi includono riferimenti a misurazioni precedenti, creando una traccia verificabile. +Una struttura dati firmata contenente la posizione geografica di un [DZD](#dzd-doublezero-device) (latitudine e longitudine) e una catena di relazioni di latenza tra entità (DZD↔Probe o Probe↔Target). I LocationOffset sono firmati con Ed25519 e inviati tramite UDP attraverso la catena di misurazione. Gli offset compositi includono riferimenti a misurazioni precedenti, creando una traccia verificabile. --- ## Blockchain e Chiavi ### Onchain -Nel contesto DoubleZero, onchain si riferisce a dati e operazioni registrati sul ledger DoubleZero. A differenza delle reti tradizionali dove le configurazioni di dispositivi e link risiedono in sistemi di gestione centralizzati, DoubleZero registra le registrazioni dei dispositivi, le configurazioni dei link e gli invii di telemetria onchain — rendendo lo stato della rete trasparente e verificabile da tutti i partecipanti. +Nel contesto DoubleZero, onchain si riferisce a dati e operazioni registrati sul ledger DoubleZero. A differenza delle reti tradizionali in cui le configurazioni di dispositivi e link risiedono in sistemi di gestione centralizzati, DoubleZero registra le registrazioni dei dispositivi, le configurazioni dei link e le sottomissioni di telemetria onchain — rendendo lo stato della rete trasparente e verificabile da tutti i partecipanti. ### Service Key -Una coppia di chiavi crittografiche utilizzata per autenticare le operazioni CLI. Questa è la tua identità come contributore per interagire con lo smart contract DoubleZero. Memorizzata in `~/.config/solana/id.json`. +Una coppia di chiavi crittografiche utilizzata per autenticare le operazioni CLI. Questa è la vostra identità di contributor per interagire con lo smart contract DoubleZero. Memorizzata in `~/.config/solana/id.json`. ### Metrics Publisher Key -Una coppia di chiavi crittografiche utilizzata dal [Telemetry Agent](#telemetry-agent) per firmare gli invii di metriche alla blockchain. Separata dalla service key per l'isolamento della sicurezza. Memorizzata in `~/.config/doublezero/metrics-publisher.json`. +Una coppia di chiavi crittografiche utilizzata dal [Telemetry Agent](#telemetry-agent) per firmare le sottomissioni di metriche alla blockchain. Separata dalla service key per l'isolamento della sicurezza. Memorizzata in `~/.config/doublezero/metrics-publisher.json`. + +### Rewards Manager Key +Una coppia di chiavi crittografiche che controlla dove vengono pagati i premi di un contributor. Firma le modifiche all'elenco dei wallet destinatari ma non detiene mai direttamente i premi. Registrata rispetto alla [Service Key](#service-key) del contributor da [DZF](#dzf-doublezero-foundation). Consulta [Gestione dei Premi](contribute-rewards.md). --- ## Hardware e Software ### EOS (Extensible Operating System) -Il sistema operativo di rete di Arista che viene eseguito sugli switch DZD. I contributori installano il [Config Agent](#config-agent) e il [Telemetry Agent](#telemetry-agent) come estensioni EOS. +Il sistema operativo di rete di Arista che viene eseguito sugli switch DZD. I contributor installano il [Config Agent](#config-agent) e il [Telemetry Agent](#telemetry-agent) come estensioni EOS. ### EOS Extension -Un pacchetto software che può essere installato sugli switch Arista EOS. Gli agenti DZ vengono distribuiti come file `.rpm` e installati tramite il comando `extension`. \ No newline at end of file +Un pacchetto software che può essere installato sugli switch Arista EOS. Gli agenti DZ sono distribuiti come file `.rpm` e installati tramite il comando `extension`. \ No newline at end of file diff --git a/docs/glossary.ja.md b/docs/glossary.ja.md index 578e877..84b7a20 100644 --- a/docs/glossary.ja.md +++ b/docs/glossary.ja.md @@ -14,61 +14,61 @@ description: ドキュメント全体で使用されるDoubleZero固有の用語 DoubleZeroリンクを終端し、DoubleZero Agentソフトウェアを実行する物理ネットワークスイッチングハードウェア。DZDはデータセンターに展開され、ルーティング、パケット処理、およびユーザー接続サービスを提供します。各DZDには特定の[ハードウェア仕様](contribute.md#dzd-network-hardware)が必要であり、[Config Agent](#config-agent)と[Telemetry Agent](#telemetry-agent)の両方を実行します。 ### DZX (DoubleZero Exchange) -メッシュネットワーク内の相互接続ポイントで、異なる[コントリビューター](#contributor)のリンクがブリッジされます。DZXは、ネットワークの交差点が発生する主要な都市圏（例：NYC、LON、TYO）に設置されています。ネットワークコントリビューターは、最寄りのDZXで自身のリンクをより広範なDoubleZeroメッシュにクロスコネクトする必要があります。Internet Exchange (IX) と概念的に類似しています。 +メッシュネットワーク内の相互接続ポイントで、異なる[コントリビューター](#contributor)のリンクがブリッジされる場所です。DZXは、ネットワークの交差点が発生する主要な都市圏（例：NYC、LON、TYO）に設置されています。ネットワークコントリビューターは、最寄りのDZXで自身のリンクをより広範なDoubleZeroメッシュにクロスコネクトする必要があります。Internet Exchange (IX) と同様の概念です。 -### WAN Link -**同じ**コントリビューターが運用する2つの[DZD](#dzd-doublezero-device)間のWide Area Networkリンク。WANリンクは、単一のコントリビューターのインフラストラクチャ内でバックボーン接続を提供します。 +### WANリンク +**同一の**コントリビューターによって運用される2つの[DZD](#dzd-doublezero-device)間のWide Area Networkリンク。WANリンクは、単一のコントリビューターのインフラストラクチャ内でバックボーン接続を提供します。 -### DZX Link -[DZX](#dzx-doublezero-exchange)で確立される、**異なる**コントリビューターが運用する[DZD](#dzd-doublezero-device)間のリンク。DZXリンクは双方の明示的な承諾が必要です。 +### DZXリンク +[DZX](#dzx-doublezero-exchange)で確立される、**異なる**コントリビューターによって運用される[DZD](#dzd-doublezero-device)間のリンク。DZXリンクは双方の明示的な承認が必要です。 -### DZ Prefix -オーバーレイネットワークアドレッシングのために[DZD](#dzd-doublezero-device)に割り当てられるCIDR形式のIPアドレス割り当て。[デバイス作成](contribute-provisioning.md#step-32-create-your-device-onchain)時に`--dz-prefixes`パラメータを使用して指定されます。 +### DZプレフィックス +オーバーレイネットワークアドレッシングのために[DZD](#dzd-doublezero-device)に割り当てられたCIDR形式のIPアドレス割り当て。[デバイス作成](contribute-provisioning.md#step-32-create-your-device-onchain)時に`--dz-prefixes`パラメータを使用して指定します。 --- ## デバイスタイプ -### Edge Device -DoubleZeroネットワークへのユーザー接続を提供する[DZD](#dzd-doublezero-device)。Edgeデバイスは[CYOA](#cyoa-choose-your-own-adventure)インターフェースを活用して、ユーザー（バリデーター、RPCオペレーター）を終端し、ネットワークに接続します。 +### エッジデバイス +DoubleZeroネットワークへのユーザー接続を提供する[DZD](#dzd-doublezero-device)。エッジデバイスは[CYOA](#cyoa-choose-your-own-adventure)インターフェースを活用してユーザー（バリデーター、RPCオペレーター）を終端し、ネットワークに接続します。 -### Transit Device -DoubleZeroネットワーク内でバックボーン接続を提供する[DZD](#dzd-doublezero-device)。Transitデバイスは、DZD間のトラフィックを移動させますが、ユーザー接続を直接終端しません。 +### トランジットデバイス +DoubleZeroネットワーク内でバックボーン接続を提供する[DZD](#dzd-doublezero-device)。トランジットデバイスはDZD間のトラフィックを転送しますが、ユーザー接続を直接終端することはありません。 -### Hybrid Device -[Edge](#edge-device)と[Transit](#transit-device)の両方の機能を組み合わせた[DZD](#dzd-doublezero-device)で、ユーザー接続とバックボーンルーティングの両方を提供します。 +### ハイブリッドデバイス +[エッジ](#edge-device)と[トランジット](#transit-device)の両方の機能を兼ね備えた[DZD](#dzd-doublezero-device)で、ユーザー接続とバックボーンルーティングの両方を提供します。 --- ## 接続性 ### CYOA (Choose Your Own Adventure) -[コントリビューター](#contributor)がDoubleZeroネットワークにユーザーを接続するための接続オプションを登録できるインターフェースタイプ。CYOAインターフェースには、[DIA](#dia-direct-internet-access)、GREトンネル、プライベートピアリングなどのさまざまな方法が含まれます。設定の詳細については[CYOAインターフェースの作成](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)を参照してください。 +[コントリビューター](#contributor)がユーザーのDoubleZeroネットワークへの接続オプションを登録できるインターフェースタイプ。CYOAインターフェースには、[DIA](#dia-direct-internet-access)、GREトンネル、プライベートピアリングなど、さまざまな方法が含まれます。設定の詳細については[CYOAインターフェースの作成](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)を参照してください。 ### DIA (Direct Internet Access) -パブリックインターネット経由で提供される接続の標準的なネットワーキング用語。DoubleZeroでは、DIAはユーザー（バリデーター、RPCオペレーター）が既存のインターネット接続を介して[DZD](#dzd-doublezero-device)に接続する[CYOA](#cyoa-choose-your-own-adventure)インターフェースタイプです。 +パブリックインターネット経由で提供される接続に関する標準的なネットワーキング用語。DoubleZeroでは、DIAはユーザー（バリデーター、RPCオペレーター）が既存のインターネット接続を通じて[DZD](#dzd-doublezero-device)に接続する[CYOA](#cyoa-choose-your-own-adventure)インターフェースタイプです。 ### IBRL (Increase Bandwidth Reduce Latency) バリデーターやRPCノードがブロックチェーンクライアントを再起動せずにDoubleZeroに接続できる接続モード。IBRLは既存のパブリックIPアドレスを使用し、最寄りの[DZD](#dzd-doublezero-device)へのオーバーレイトンネルを確立します。セットアップ手順については[Mainnet-Beta接続](DZ%20Mainnet-beta%20Connection.md)を参照してください。 -### Multicast -DoubleZeroがサポートする1対多のパケット配信方式。Multicastモードには2つの役割があります：**パブリッシャー**（ネットワーク全体にパケットを送信）と**サブスクライバー**（パブリッシャーからパケットを受信）。開発チームによる効率的なデータ配信に使用されます。接続の詳細については[その他のMulticast接続](Other%20Multicast%20Connection.md)を参照してください。 +### マルチキャスト +DoubleZeroがサポートする1対多のパケット配信方式。マルチキャストモードには、**パブリッシャー**（ネットワーク全体にパケットを送信）と**サブスクライバー**（パブリッシャーからパケットを受信）の2つの役割があります。開発チームが効率的なデータ配信に使用します。接続の詳細については[その他のマルチキャスト接続](Other%20Multicast%20Connection.md)を参照してください。 --- ## ソフトウェアコンポーネント ### doublezerod -ユーザーサーバー（バリデーター、RPCノード）上で実行されるDoubleZeroデーモンサービス。DoubleZeroネットワークへの接続を管理し、トンネルの確立を処理し、[DZD](#dzd-doublezero-device)への接続を維持します。systemdを介して設定され、[`doublezero`](#doublezero-cli) CLIを通じて制御されます。 +ユーザーサーバー（バリデーター、RPCノード）上で実行されるDoubleZeroデーモンサービス。DoubleZeroネットワークへの接続を管理し、トンネルの確立を処理し、[DZD](#dzd-doublezero-device)への接続性を維持します。systemdを介して設定され、[`doublezero`](#doublezero-cli) CLIを通じて制御されます。 ### doublezero (CLI) -DoubleZeroネットワークとやり取りするためのコマンドラインインターフェース。接続、ID管理、ステータス確認、管理操作に使用されます。[`doublezerod`](#doublezerod)デーモンと通信します。 +DoubleZeroネットワークとやり取りするためのコマンドラインインターフェース。接続、アイデンティティの管理、ステータスの確認、および管理操作に使用されます。[`doublezerod`](#doublezerod)デーモンと通信します。 ### Config Agent -[DZD](#dzd-doublezero-device)上で実行され、デバイス設定を管理するソフトウェアエージェント。[Controller](#controller)サービスから設定を読み取り、デバイスに変更を適用します。セットアップについては[Config Agentのインストール](contribute-provisioning.md#step-44-install-config-agent)を参照してください。 +[DZD](#dzd-doublezero-device)上で実行されるソフトウェアエージェントで、デバイス設定を管理します。[Controller](#controller)サービスから設定を読み取り、デバイスに変更を適用します。セットアップについては[Config Agentのインストール](contribute-provisioning.md#step-44-install-config-agent)を参照してください。 ### Telemetry Agent -[DZD](#dzd-doublezero-device)上で実行され、パフォーマンスメトリクス（レイテンシー、ジッター、パケットロス）を収集してDoubleZero台帳に送信するソフトウェアエージェント。セットアップについては[Telemetry Agentのインストール](contribute-provisioning.md#step-45-install-telemetry-agent)を参照してください。 +[DZD](#dzd-doublezero-device)上で実行されるソフトウェアエージェントで、パフォーマンスメトリクス（レイテンシ、ジッター、パケットロス）を収集し、DoubleZero台帳に送信します。セットアップについては[Telemetry Agentのインストール](contribute-provisioning.md#step-45-install-telemetry-agent)を参照してください。 ### Controller [DZD](#dzd-doublezero-device)エージェントに設定を提供するサービス。ControllerはDoubleZero台帳上の[オンチェーン](#onchain)状態からデバイス設定を導出します。 @@ -77,97 +77,100 @@ DoubleZeroネットワークとやり取りするためのコマンドライン ## リンク状態 -### Activated -リンクの通常の運用状態。トラフィックはリンクを通過し、ルーティング判断に参加します。 +### アクティベート済み +リンクの通常の運用状態。トラフィックがリンクを通過し、ルーティング決定に参加します。 -### Soft-Drained -特定のリンクでトラフィックが抑制されるメンテナンス状態。グレースフルなメンテナンスウィンドウに使用されます。[activated](#activated)または[hard-drained](#hard-drained)に遷移できます。 +### ソフトドレイン +特定のリンクでトラフィックが抑制されるメンテナンス状態。グレースフルなメンテナンスウィンドウに使用されます。[アクティベート済み](#activated)または[ハードドレイン](#hard-drained)に移行できます。 -### Hard-Drained -リンクがサービスから完全に除外されるメンテナンス状態。トラフィックはリンクを通過しません。[activated](#activated)に戻るには、事前に[soft-drained](#soft-drained)に遷移する必要があります。 +### ハードドレイン +リンクがサービスから完全に除外されるメンテナンス状態。リンクを通過するトラフィックはありません。[アクティベート済み](#activated)に戻る前に[ソフトドレイン](#soft-drained)に移行する必要があります。 --- -## 組織 & トークン +## 組織とトークン ### DZF (DoubleZero Foundation) -DoubleZero Foundationは、DoubleZeroネットワークの開発、分散化、セキュリティ、および普及を支援するために設立されたメンバーレスの非営利ケイマン諸島財団法人です。 +DoubleZero Foundationは、DoubleZeroネットワークの開発、分散化、セキュリティ、および普及を支援するために設立された、メンバーを持たないケイマン諸島の非営利財団法人です。 -### 2Z Token -DoubleZeroネットワークのネイティブトークン。バリデーター手数料の支払いに使用され、[コントリビューター](#contributor)への報酬として配布されます。バリデーターはオンチェーンスワッププログラムを介して2Zで手数料を支払うことができます。[SOLから2Zへのスワップ](Swapping-sol-to-2z.md)を参照してください。 +### 2Zトークン +DoubleZeroネットワークのネイティブトークン。バリデーター手数料の支払いに使用され、[コントリビューター](#contributor)への報酬として配布されます。バリデーターはオンチェーンスワッププログラムを通じて2Zで手数料を支払うことができます。[SOLから2Zへのスワップ](Swapping-sol-to-2z.md)を参照してください。 -### Contributor -DoubleZeroネットワークに帯域幅とハードウェアを提供するネットワークインフラストラクチャプロバイダー。コントリビューターは[DZD](#dzd-doublezero-device)を運用し、[WAN](#wan-link)および[DZX](#dzx-link)リンクを提供し、その貢献に対して[2Z](#2z-token)トークンインセンティブを受け取ります。開始するには[コントリビュータードキュメント](contribute-overview.md)を参照してください。 +### コントリビューター +DoubleZeroネットワークに帯域幅とハードウェアを提供するネットワークインフラストラクチャプロバイダー。コントリビューターは[DZD](#dzd-doublezero-device)を運用し、[WAN](#wanリンク)および[DZX](#dzxリンク)リンクを提供し、その貢献に対して[2Z](#2zトークン)トークンインセンティブを受け取ります。開始するには[コントリビュータードキュメント](contribute-overview.md)を参照してください。 --- -## ネットワーキングの概念 +## ネットワーキング概念 ### MTU (Maximum Transmission Unit) -ネットワークリンク上で送信可能な最大パケットサイズ（バイト単位）。DoubleZero WANリンクは通常、効率性のためにMTU 9000（ジャンボフレーム）を使用します。 +ネットワークリンク上で送信可能な最大パケットサイズ（バイト単位）。DoubleZeroのWANリンクは通常、効率性のためにMTU 9000（ジャンボフレーム）を使用します。 ### VRF (Virtual Routing and Forwarding) -同じ物理ルーター上に複数の分離されたルーティングテーブルを存在させることを可能にする技術。コントリビューターは、スイッチ管理トラフィックを本番トラフィックから分離するために、別の管理VRFを使用することがよくあります。 +同一の物理ルーター上に複数の分離されたルーティングテーブルを存在させる技術。コントリビューターは多くの場合、スイッチ管理トラフィックを本番トラフィックから分離するために別の管理VRFを使用します。 ### GRE (Generic Routing Encapsulation) -ネットワークパケットをIPパケット内にカプセル化するトンネリングプロトコル。[IBRL](#ibrl-increase-bandwidth-reduce-latency)および[CYOA](#cyoa-choose-your-own-adventure)接続で、ユーザーとDZD間にオーバーレイトンネルを作成するために使用されます。 +ネットワークパケットをIPパケット内にカプセル化するトンネリングプロトコル。[IBRL](#ibrl-increase-bandwidth-reduce-latency)および[CYOA](#cyoa-choose-your-own-adventure)接続で、ユーザーとDZD間のオーバーレイトンネルを作成するために使用されます。 ### BGP (Border Gateway Protocol) -インターネット上のネットワーク間でルーティング情報を交換するために使用されるルーティングプロトコル。DoubleZeroは内部的にASN 65342でBGPを使用します。 +インターネット上のネットワーク間でルーティング情報を交換するために使用されるルーティングプロトコル。DoubleZeroは内部的にASN 65342でBGPを使用しています。 ### ASN (Autonomous System Number) BGPルーティングのためにネットワークに割り当てられる一意の識別子。すべてのDoubleZeroデバイスは内部BGPプロセスに**ASN 65342**を使用します。 -### Loopback Interface -管理およびルーティング目的で使用されるルーター/スイッチ上の仮想ネットワークインターフェース。DZDは内部ルーティングにLoopback255（VPNv4）とLoopback256（IPv4）を使用します。 +### ループバックインターフェース +管理およびルーティング目的でルーター/スイッチ上に設定される仮想ネットワークインターフェース。DZDは内部ルーティングにLoopback255（VPNv4）およびLoopback256（IPv4）を使用します。 ### CIDR (Classless Inter-Domain Routing) IPアドレス範囲を指定するための表記法。形式は`IP/prefix-length`で、プレフィックス長はネットワークサイズを示します（例：`/29` = 8アドレス、`/24` = 256アドレス）。 -### Jitter -時間の経過に伴うパケットレイテンシーの変動。低ジッターはリアルタイムアプリケーションにとって重要です。 +### ジッター +時間の経過に伴うパケットレイテンシの変動。リアルタイムアプリケーションにとって低ジッターは極めて重要です。 ### RTT (Round-Trip Time) -パケットが送信元から宛先に到達し、戻ってくるまでの時間。デバイス間のネットワークレイテンシーを測定するために使用されます。 +パケットが送信元から宛先に到達し、戻ってくるまでの時間。デバイス間のネットワークレイテンシの測定に使用されます。 ### TWAMP (Two-Way Active Measurement Protocol) -レイテンシーやパケットロスなどのネットワークパフォーマンスメトリクスを測定するためのプロトコル。[Telemetry Agent](#telemetry-agent)はDZD間のメトリクス収集にTWAMPを使用します。 +レイテンシやパケットロスなどのネットワークパフォーマンスメトリクスを測定するためのプロトコル。[Telemetry Agent](#telemetry-agent)はTWAMPを使用してDZD間のメトリクスを収集します。 ### IS-IS (Intermediate System to Intermediate System) -DoubleZeroネットワーク内部で使用されるリンクステートルーティングプロトコル。IS-ISメトリクスは[リンクドレイニング](#soft-drained)操作時に調整されます。 +DoubleZeroネットワーク内部で使用されるリンクステートルーティングプロトコル。IS-ISメトリクスは[リンクドレイン](#soft-drained)操作中に調整されます。 --- ## ジオロケーション -### Geolocation -レイテンシー測定を使用してデバイスの物理的な位置を検証するDoubleZeroサービス。既知の場所にあるインフラストラクチャ（[DZD](#dzd-doublezero-device)）とターゲットデバイス間の[RTT](#rtt-round-trip-time)測定により、デバイスが基準点から一定の距離内にあることの暗号署名付き証明を提供します。測定のオンチェーン記録は将来のリリースで計画されています。ユーザードキュメントについては[ジオロケーション](geolocation.md)を参照してください。 +### ジオロケーション +レイテンシ測定を使用してデバイスの物理的な位置を検証するDoubleZeroサービス。既知の位置のインフラストラクチャ（[DZD](#dzd-doublezero-device)）とターゲットデバイス間の[RTT](#rtt-round-trip-time)測定により、デバイスが基準点から一定の距離内にあることの暗号学的に署名された証明が提供されます。測定のオンチェーン記録は将来のリリースで予定されています。ユーザードキュメントについては[ジオロケーション](geolocation.md)を参照してください。 ### geoProbe -[ジオロケーション](#geolocation)システムにおけるレイテンシー測定の仲介役として機能するベアメタルサーバー。geoProbeは[DZD](#dzd-doublezero-device)から約1ms以内の場所に配置され、親DZDから署名付きLocationOffsetを受信し、[TWAMP](#twamp-two-way-active-measurement-protocol)、署名付きTWAMP、またはICMP echoを介してターゲットデバイスへの[RTT](#rtt-round-trip-time)を測定します。各geoProbeは[オンチェーン](#onchain)に登録され、1つ以上の親DZDに紐づけられます。コントリビュータードキュメントについては[Geoprobeのデプロイ](contribute-geolocation.md)を参照してください。 +[ジオロケーション](#ジオロケーション)システムにおけるレイテンシ測定の仲介役として機能するベアメタルサーバー。geoProbeは[DZD](#dzd-doublezero-device)から約1ms以内の場所に設置され、親DZDから署名されたLocationOffsetを受信し、[TWAMP](#twamp-two-way-active-measurement-protocol)、署名付きTWAMP、またはICMPエコーを介してターゲットデバイスへの[RTT](#rtt-round-trip-time)を測定します。各geoProbeは[オンチェーン](#onchain)に登録され、1つ以上の親DZDにリンクされています。コントリビュータードキュメントについては[geoProbeのデプロイ](contribute-geolocation.md)を参照してください。 ### LocationOffset -[DZD](#dzd-doublezero-device)の地理的位置（緯度と経度）およびエンティティ間のレイテンシー関係チェーン（DZD↔Probe または Probe↔Target）を含む署名付きデータ構造。LocationOffsetはEd25519で署名され、測定チェーンを通じてUDPで送信されます。複合オフセットには以前の測定への参照が含まれ、監査可能なトレイルを作成します。 +[DZD](#dzd-doublezero-device)の地理的位置（緯度と経度）およびエンティティ間のレイテンシ関係チェーン（DZD↔Probe または Probe↔Target）を含む署名されたデータ構造。LocationOffsetはEd25519で署名され、測定チェーンを通じてUDP経由で送信されます。複合オフセットには以前の測定への参照が含まれ、監査可能なトレイルを作成します。 --- -## ブロックチェーン & 鍵 +## ブロックチェーンと鍵 -### Onchain -DoubleZeroの文脈では、onchainはDoubleZero台帳に記録されるデータと操作を指します。デバイスやリンクの設定が集中管理システムに存在する従来のネットワークとは異なり、DoubleZeroはデバイスの登録、リンクの設定、テレメトリーの送信をオンチェーンに記録し、ネットワーク状態をすべての参加者にとって透明で検証可能にしています。 +### オンチェーン +DoubleZeroの文脈では、オンチェーンとはDoubleZero台帳上に記録されるデータおよび操作を指します。デバイスやリンクの設定が集中管理システムに存在する従来のネットワークとは異なり、DoubleZeroはデバイス登録、リンク設定、テレメトリ送信をオンチェーンに記録し、ネットワーク状態をすべての参加者が透明かつ検証可能な形で利用できるようにします。 -### Service Key -CLI操作を認証するために使用される暗号鍵ペア。これはDoubleZeroスマートコントラクトとやり取りするためのコントリビューターIDです。`~/.config/solana/id.json`に保存されます。 +### サービスキー +CLI操作の認証に使用される暗号鍵ペア。DoubleZeroスマートコントラクトとやり取りするためのコントリビューターのアイデンティティです。`~/.config/solana/id.json`に保存されます。 -### Metrics Publisher Key -[Telemetry Agent](#telemetry-agent)がブロックチェーンへのメトリクス送信に署名するために使用する暗号鍵ペア。セキュリティ分離のためにService Keyとは別になっています。`~/.config/doublezero/metrics-publisher.json`に保存されます。 +### メトリクスパブリッシャーキー +[Telemetry Agent](#telemetry-agent)がブロックチェーンへのメトリクス送信に署名するために使用する暗号鍵ペア。セキュリティ分離のためにサービスキーとは分離されています。`~/.config/doublezero/metrics-publisher.json`に保存されます。 + +### リワードマネージャーキー +コントリビューターの報酬の支払い先を制御する暗号鍵ペア。受取ウォレットリストの変更に署名しますが、報酬自体を保持することはありません。[DZF](#dzf-doublezero-foundation)によってコントリビューターの[サービスキー](#サービスキー)に対して登録されます。[報酬管理](contribute-rewards.md)を参照してください。 --- -## ハードウェア & ソフトウェア +## ハードウェアとソフトウェア ### EOS (Extensible Operating System) -DZDスイッチ上で実行されるAristaのネットワークオペレーティングシステム。コントリビューターは[Config Agent](#config-agent)と[Telemetry Agent](#telemetry-agent)をEOS拡張としてインストールします。 +DZDスイッチ上で動作するAristaのネットワークオペレーティングシステム。コントリビューターは[Config Agent](#config-agent)と[Telemetry Agent](#telemetry-agent)をEOS拡張としてインストールします。 -### EOS Extension +### EOS拡張 Arista EOSスイッチにインストールできるソフトウェアパッケージ。DZエージェントは`.rpm`ファイルとして配布され、`extension`コマンドを介してインストールされます。 \ No newline at end of file diff --git a/docs/glossary.ko.md b/docs/glossary.ko.md index 5fe6112..a862080 100644 --- a/docs/glossary.ko.md +++ b/docs/glossary.ko.md @@ -1,77 +1,77 @@ --- -description: 문서 전반에 사용되는 DoubleZero 전용 용어 정의. +description: 문서 전반에서 사용되는 DoubleZero 전용 용어 정의. --- # 용어집 -이 페이지는 문서 전반에 사용되는 DoubleZero 전용 용어를 정의합니다. +이 페이지는 문서 전반에서 사용되는 DoubleZero 전용 용어를 정의합니다. --- ## 네트워크 인프라 ### DZD (DoubleZero Device) -DoubleZero 링크를 종단하고 DoubleZero Agent 소프트웨어를 실행하는 물리적 네트워크 스위칭 하드웨어입니다. DZD는 데이터 센터에 배포되며 라우팅, 패킷 처리 및 사용자 연결 서비스를 제공합니다. 각 DZD는 특정 [하드웨어 사양](contribute.md#dzd-network-hardware)을 충족해야 하며 [Config Agent](#config-agent)와 [Telemetry Agent](#telemetry-agent)를 모두 실행합니다. +DoubleZero 링크를 종단하고 DoubleZero Agent 소프트웨어를 실행하는 물리적 네트워크 스위칭 하드웨어입니다. DZD는 데이터 센터에 배포되며 라우팅, 패킷 처리 및 사용자 연결 서비스를 제공합니다. 각 DZD는 특정 [하드웨어 사양](contribute.md#dzd-network-hardware)을 요구하며 [Config Agent](#config-agent)와 [Telemetry Agent](#telemetry-agent)를 모두 실행합니다. ### DZX (DoubleZero Exchange) -서로 다른 [기여자](#contributor) 링크가 연결되는 메시 네트워크의 상호 연결 지점입니다. DZX는 네트워크 교차점이 발생하는 주요 대도시 지역(예: NYC, LON, TYO)에 위치합니다. 네트워크 기여자는 가장 가까운 DZX에서 자신의 링크를 더 넓은 DoubleZero 메시에 크로스 커넥트해야 합니다. 인터넷 교환소(IX)와 유사한 개념입니다. +서로 다른 [기여자](#contributor) 링크가 브리징되는 메시 네트워크의 상호 연결 지점입니다. DZX는 네트워크 교차가 발생하는 주요 대도시 지역(예: NYC, LON, TYO)에 위치합니다. 네트워크 기여자는 가장 가까운 DZX에서 자신의 링크를 더 넓은 DoubleZero 메시에 크로스커넥트해야 합니다. 인터넷 교환소(IX)와 유사한 개념입니다. ### WAN Link -**동일한** 기여자가 운영하는 두 [DZD](#dzd-doublezero-device) 간의 광역 네트워크 링크입니다. WAN 링크는 단일 기여자 인프라 내에서 백본 연결을 제공합니다. +**동일한** 기여자가 운영하는 두 [DZD](#dzd-doublezero-device) 간의 광역 네트워크 링크입니다. WAN 링크는 단일 기여자의 인프라 내에서 백본 연결을 제공합니다. ### DZX Link -**서로 다른** 기여자가 운영하는 [DZD](#dzd-doublezero-device) 간에 [DZX](#dzx-doublezero-exchange)에서 설정되는 링크입니다. DZX 링크는 양측 모두의 명시적 수락이 필요합니다. +[DZX](#dzx-doublezero-exchange)에서 설정된, **서로 다른** 기여자가 운영하는 [DZD](#dzd-doublezero-device) 간의 링크입니다. DZX 링크는 양측의 명시적인 수락이 필요합니다. ### DZ Prefix -오버레이 네트워크 주소 지정을 위해 [DZD](#dzd-doublezero-device)에 할당되는 CIDR 형식의 IP 주소 할당입니다. [디바이스 생성](contribute-provisioning.md#step-32-create-your-device-onchain) 시 `--dz-prefixes` 매개변수를 사용하여 지정합니다. +오버레이 네트워크 주소 지정을 위해 [DZD](#dzd-doublezero-device)에 할당된 CIDR 형식의 IP 주소 할당입니다. [디바이스 생성](contribute-provisioning.md#step-32-create-your-device-onchain) 시 `--dz-prefixes` 매개변수를 사용하여 지정합니다. --- ## 디바이스 유형 ### Edge Device -DoubleZero 네트워크에 대한 사용자 연결을 제공하는 [DZD](#dzd-doublezero-device)입니다. Edge 디바이스는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스를 활용하여 사용자(밸리데이터, RPC 운영자)를 종단하고 네트워크에 연결합니다. +DoubleZero 네트워크에 대한 사용자 연결을 제공하는 [DZD](#dzd-doublezero-device)입니다. Edge 디바이스는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스를 활용하여 사용자(검증자, RPC 운영자)를 종단하고 네트워크에 연결합니다. ### Transit Device DoubleZero 네트워크 내에서 백본 연결을 제공하는 [DZD](#dzd-doublezero-device)입니다. Transit 디바이스는 DZD 간에 트래픽을 이동시키지만 사용자 연결을 직접 종단하지는 않습니다. ### Hybrid Device -[edge](#edge-device)와 [transit](#transit-device) 기능을 모두 결합하여 사용자 연결과 백본 라우팅을 모두 제공하는 [DZD](#dzd-doublezero-device)입니다. +[Edge](#edge-device)와 [Transit](#transit-device) 기능을 모두 결합하여 사용자 연결과 백본 라우팅을 모두 제공하는 [DZD](#dzd-doublezero-device)입니다. --- -## 연결 +## 연결성 ### CYOA (Choose Your Own Adventure) -[기여자](#contributor)가 사용자가 DoubleZero 네트워크에 연결할 수 있는 연결 옵션을 등록할 수 있게 하는 인터페이스 유형입니다. CYOA 인터페이스에는 [DIA](#dia-direct-internet-access), GRE 터널, 프라이빗 피어링 등 다양한 방법이 포함됩니다. 구성 세부 사항은 [CYOA 인터페이스 생성](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)을 참조하세요. +[기여자](#contributor)가 사용자가 DoubleZero 네트워크에 연결할 수 있는 연결 옵션을 등록할 수 있게 해주는 인터페이스 유형입니다. CYOA 인터페이스에는 [DIA](#dia-direct-internet-access), GRE 터널, 프라이빗 피어링 등 다양한 방법이 포함됩니다. 구성 세부 사항은 [CYOA 인터페이스 생성](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)을 참조하세요. ### DIA (Direct Internet Access) -공용 인터넷을 통해 제공되는 연결을 의미하는 표준 네트워킹 용어입니다. DoubleZero에서 DIA는 사용자(밸리데이터, RPC 운영자)가 기존 인터넷 연결을 통해 [DZD](#dzd-doublezero-device)에 연결하는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스 유형입니다. +공용 인터넷을 통해 제공되는 연결에 대한 표준 네트워킹 용어입니다. DoubleZero에서 DIA는 사용자(검증자, RPC 운영자)가 기존 인터넷 연결을 통해 [DZD](#dzd-doublezero-device)에 연결하는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스 유형입니다. ### IBRL (Increase Bandwidth Reduce Latency) -밸리데이터와 RPC 노드가 블록체인 클라이언트를 재시작하지 않고 DoubleZero에 연결할 수 있게 하는 연결 모드입니다. IBRL은 기존 공용 IP 주소를 사용하고 가장 가까운 [DZD](#dzd-doublezero-device)에 오버레이 터널을 설정합니다. 설정 방법은 [Mainnet-Beta 연결](DZ%20Mainnet-beta%20Connection.md)을 참조하세요. +검증자 및 RPC 노드가 블록체인 클라이언트를 재시작하지 않고 DoubleZero에 연결할 수 있게 해주는 연결 모드입니다. IBRL은 기존 공용 IP 주소를 사용하며 가장 가까운 [DZD](#dzd-doublezero-device)로의 오버레이 터널을 설정합니다. 설정 지침은 [Mainnet-Beta 연결](DZ%20Mainnet-beta%20Connection.md)을 참조하세요. ### Multicast -DoubleZero가 지원하는 일대다 패킷 전달 방식입니다. Multicast 모드에는 두 가지 역할이 있습니다: **퍼블리셔**(네트워크를 통해 패킷 전송)와 **구독자**(퍼블리셔로부터 패킷 수신). 개발 팀이 효율적인 데이터 배포를 위해 사용합니다. 연결 세부 사항은 [기타 Multicast 연결](Other%20Multicast%20Connection.md)을 참조하세요. +DoubleZero에서 지원하는 일대다 패킷 전달 방법입니다. Multicast 모드에는 두 가지 역할이 있습니다: **퍼블리셔**(네트워크를 통해 패킷 전송)와 **구독자**(퍼블리셔로부터 패킷 수신). 개발 팀에서 효율적인 데이터 배포를 위해 사용합니다. 연결 세부 사항은 [기타 Multicast 연결](Other%20Multicast%20Connection.md)을 참조하세요. --- ## 소프트웨어 구성 요소 ### doublezerod -사용자 서버(밸리데이터, RPC 노드)에서 실행되는 DoubleZero 데몬 서비스입니다. DoubleZero 네트워크 연결을 관리하고, 터널 설정을 처리하며, [DZD](#dzd-doublezero-device)와의 연결을 유지합니다. systemd를 통해 구성되며 [`doublezero`](#doublezero-cli) CLI를 통해 제어됩니다. +사용자 서버(검증자, RPC 노드)에서 실행되는 DoubleZero 데몬 서비스입니다. DoubleZero 네트워크에 대한 연결을 관리하고, 터널 설정을 처리하며, [DZD](#dzd-doublezero-device)에 대한 연결을 유지합니다. systemd를 통해 구성되며 [`doublezero`](#doublezero-cli) CLI를 통해 제어됩니다. ### doublezero (CLI) -DoubleZero 네트워크와 상호 작용하기 위한 명령줄 인터페이스입니다. 연결, ID 관리, 상태 확인 및 관리 작업에 사용됩니다. [`doublezerod`](#doublezerod) 데몬과 통신합니다. +DoubleZero 네트워크와 상호작용하기 위한 명령줄 인터페이스입니다. 연결, ID 관리, 상태 확인 및 관리 작업에 사용됩니다. [`doublezerod`](#doublezerod) 데몬과 통신합니다. ### Config Agent -[DZD](#dzd-doublezero-device)에서 실행되며 디바이스 구성을 관리하는 소프트웨어 에이전트입니다. [Controller](#controller) 서비스에서 구성을 읽고 디바이스에 변경 사항을 적용합니다. 설정은 [Config Agent 설치](contribute-provisioning.md#step-44-install-config-agent)를 참조하세요. +디바이스 구성을 관리하는 [DZD](#dzd-doublezero-device)에서 실행되는 소프트웨어 에이전트입니다. [Controller](#controller) 서비스에서 구성을 읽어 디바이스에 변경 사항을 적용합니다. 설정은 [Config Agent 설치](contribute-provisioning.md#step-44-install-config-agent)를 참조하세요. ### Telemetry Agent -[DZD](#dzd-doublezero-device)에서 실행되며 성능 메트릭(지연 시간, 지터, 패킷 손실)을 수집하고 DoubleZero 레저에 제출하는 소프트웨어 에이전트입니다. 설정은 [Telemetry Agent 설치](contribute-provisioning.md#step-45-install-telemetry-agent)를 참조하세요. +성능 메트릭(지연 시간, 지터, 패킷 손실)을 수집하고 DoubleZero 원장에 제출하는 [DZD](#dzd-doublezero-device)에서 실행되는 소프트웨어 에이전트입니다. 설정은 [Telemetry Agent 설치](contribute-provisioning.md#step-45-install-telemetry-agent)를 참조하세요. ### Controller -[DZD](#dzd-doublezero-device) 에이전트에 구성을 제공하는 서비스입니다. Controller는 DoubleZero 레저의 [온체인](#onchain) 상태에서 디바이스 구성을 도출합니다. +[DZD](#dzd-doublezero-device) 에이전트에 구성을 제공하는 서비스입니다. Controller는 DoubleZero 원장의 [온체인](#onchain) 상태에서 디바이스 구성을 도출합니다. --- @@ -81,10 +81,10 @@ DoubleZero 네트워크와 상호 작용하기 위한 명령줄 인터페이스 링크의 정상 운영 상태입니다. 트래픽이 링크를 통해 흐르며 라우팅 결정에 참여합니다. ### Soft-Drained -특정 링크에서 트래픽이 억제되는 유지 보수 상태입니다. 정상적인 유지 보수 기간에 사용됩니다. [activated](#activated) 또는 [hard-drained](#hard-drained)로 전환할 수 있습니다. +특정 링크에서 트래픽이 억제되는 유지보수 상태입니다. 원활한 유지보수 기간에 사용됩니다. [activated](#activated) 또는 [hard-drained](#hard-drained)로 전환할 수 있습니다. ### Hard-Drained -링크가 서비스에서 완전히 제거되는 유지 보수 상태입니다. 링크를 통해 트래픽이 흐르지 않습니다. [activated](#activated)로 복귀하려면 먼저 [soft-drained](#soft-drained)로 전환해야 합니다. +링크가 서비스에서 완전히 제거되는 유지보수 상태입니다. 링크를 통해 트래픽이 흐르지 않습니다. [activated](#activated)로 돌아가려면 먼저 [soft-drained](#soft-drained)로 전환해야 합니다. --- @@ -94,7 +94,7 @@ DoubleZero 네트워크와 상호 작용하기 위한 명령줄 인터페이스 DoubleZero Foundation은 DoubleZero 네트워크의 개발, 탈중앙화, 보안 및 채택을 지원하기 위해 설립된 회원 없는 비영리 케이맨 제도 재단 법인입니다. ### 2Z Token -DoubleZero 네트워크의 네이티브 토큰입니다. 밸리데이터 수수료 지불에 사용되며 [기여자](#contributor)에게 보상으로 분배됩니다. 밸리데이터는 온체인 스왑 프로그램을 통해 2Z로 수수료를 지불할 수 있습니다. [SOL을 2Z로 스왑하기](Swapping-sol-to-2z.md)를 참조하세요. +DoubleZero 네트워크의 네이티브 토큰입니다. 검증자 수수료 지불에 사용되며 [기여자](#contributor)에게 보상으로 배분됩니다. 검증자는 온체인 스왑 프로그램을 통해 2Z로 수수료를 지불할 수 있습니다. [SOL을 2Z로 스왑하기](Swapping-sol-to-2z.md)를 참조하세요. ### Contributor DoubleZero 네트워크에 대역폭과 하드웨어를 기여하는 네트워크 인프라 제공자입니다. 기여자는 [DZD](#dzd-doublezero-device)를 운영하고, [WAN](#wan-link) 및 [DZX](#dzx-link) 링크를 제공하며, 기여에 대한 [2Z](#2z-token) 토큰 인센티브를 받습니다. 시작하려면 [기여자 문서](contribute-overview.md)를 참조하세요. @@ -107,16 +107,16 @@ DoubleZero 네트워크에 대역폭과 하드웨어를 기여하는 네트워 네트워크 링크를 통해 전송할 수 있는 최대 패킷 크기(바이트)입니다. DoubleZero WAN 링크는 효율성을 위해 일반적으로 MTU 9000(점보 프레임)을 사용합니다. ### VRF (Virtual Routing and Forwarding) -동일한 물리적 라우터에 여러 격리된 라우팅 테이블을 존재할 수 있게 하는 기술입니다. 기여자는 스위치 관리 트래픽을 프로덕션 트래픽과 격리하기 위해 별도의 관리 VRF를 사용하는 경우가 많습니다. +동일한 물리적 라우터에 여러 개의 격리된 라우팅 테이블이 존재할 수 있게 해주는 기술입니다. 기여자는 종종 별도의 관리 VRF를 사용하여 스위치 관리 트래픽을 프로덕션 트래픽에서 격리합니다. ### GRE (Generic Routing Encapsulation) -네트워크 패킷을 IP 패킷 내에 캡슐화하는 터널링 프로토콜입니다. [IBRL](#ibrl-increase-bandwidth-reduce-latency) 및 [CYOA](#cyoa-choose-your-own-adventure) 연결에서 사용자와 DZD 간에 오버레이 터널을 생성하는 데 사용됩니다. +네트워크 패킷을 IP 패킷 내부에 캡슐화하는 터널링 프로토콜입니다. [IBRL](#ibrl-increase-bandwidth-reduce-latency) 및 [CYOA](#cyoa-choose-your-own-adventure) 연결에서 사용자와 DZD 간에 오버레이 터널을 생성하는 데 사용됩니다. ### BGP (Border Gateway Protocol) -인터넷에서 네트워크 간 라우팅 정보를 교환하는 데 사용되는 라우팅 프로토콜입니다. DoubleZero는 ASN 65342로 내부적으로 BGP를 사용합니다. +인터넷 상의 네트워크 간 라우팅 정보를 교환하는 데 사용되는 라우팅 프로토콜입니다. DoubleZero는 내부적으로 ASN 65342를 사용하여 BGP를 사용합니다. ### ASN (Autonomous System Number) -BGP 라우팅을 위해 네트워크에 할당되는 고유 식별자입니다. 모든 DoubleZero 디바이스는 내부 BGP 프로세스에 **ASN 65342**를 사용합니다. +BGP 라우팅을 위해 네트워크에 할당된 고유 식별자입니다. 모든 DoubleZero 디바이스는 내부 BGP 프로세스에 **ASN 65342**를 사용합니다. ### Loopback Interface 관리 및 라우팅 목적으로 라우터/스위치에서 사용되는 가상 네트워크 인터페이스입니다. DZD는 내부 라우팅을 위해 Loopback255(VPNv4)와 Loopback256(IPv4)을 사용합니다. @@ -128,46 +128,49 @@ IP 주소 범위를 지정하기 위한 표기법입니다. 형식은 `IP/prefix 시간에 따른 패킷 지연 시간의 변동입니다. 낮은 지터는 실시간 애플리케이션에 매우 중요합니다. ### RTT (Round-Trip Time) -패킷이 소스에서 목적지로 이동하고 돌아오는 데 걸리는 시간입니다. 디바이스 간 네트워크 지연 시간을 측정하는 데 사용됩니다. +패킷이 출발지에서 목적지까지 이동하고 돌아오는 데 걸리는 시간입니다. 디바이스 간 네트워크 지연 시간을 측정하는 데 사용됩니다. ### TWAMP (Two-Way Active Measurement Protocol) -지연 시간 및 패킷 손실과 같은 네트워크 성능 메트릭을 측정하기 위한 프로토콜입니다. [Telemetry Agent](#telemetry-agent)는 DZD 간 메트릭을 수집하기 위해 TWAMP를 사용합니다. +지연 시간 및 패킷 손실과 같은 네트워크 성능 메트릭을 측정하기 위한 프로토콜입니다. [Telemetry Agent](#telemetry-agent)는 TWAMP를 사용하여 DZD 간의 메트릭을 수집합니다. ### IS-IS (Intermediate System to Intermediate System) -DoubleZero 네트워크에서 내부적으로 사용되는 링크 상태 라우팅 프로토콜입니다. IS-IS 메트릭은 [링크 드레이닝](#soft-drained) 작업 중에 조정됩니다. +DoubleZero 네트워크 내부에서 사용되는 링크 상태 라우팅 프로토콜입니다. IS-IS 메트릭은 [링크 드레이닝](#soft-drained) 작업 중에 조정됩니다. --- ## 지리적 위치 확인 ### Geolocation -지연 시간 측정을 사용하여 디바이스의 물리적 위치를 검증하는 DoubleZero 서비스입니다. 알려진 위치의 인프라([DZD](#dzd-doublezero-device))와 대상 디바이스 간의 [RTT](#rtt-round-trip-time) 측정은 디바이스가 기준점에서 특정 거리 이내에 있다는 암호학적 서명된 증명을 제공합니다. 측정값의 온체인 기록은 향후 릴리스에서 계획되어 있습니다. 사용자 문서는 [Geolocation](geolocation.md)을 참조하세요. +지연 시간 측정을 사용하여 디바이스의 물리적 위치를 검증하는 DoubleZero 서비스입니다. 알려진 위치의 인프라([DZD](#dzd-doublezero-device))와 대상 디바이스 간의 [RTT](#rtt-round-trip-time) 측정은 디바이스가 기준점의 특정 거리 내에 있다는 암호학적으로 서명된 증명을 제공합니다. 측정의 온체인 기록은 향후 릴리스에 계획되어 있습니다. 사용자 문서는 [Geolocation](geolocation.md)을 참조하세요. ### geoProbe -[Geolocation](#geolocation) 시스템에서 지연 시간 측정의 중간 매개체 역할을 하는 베어 메탈 서버입니다. geoProbe는 [DZD](#dzd-doublezero-device)에서 ~1ms 이내에 위치하며, 상위 DZD로부터 서명된 LocationOffset을 수신하고, [TWAMP](#twamp-two-way-active-measurement-protocol), 서명된 TWAMP 또는 ICMP echo를 통해 대상 디바이스까지의 [RTT](#rtt-round-trip-time)를 측정합니다. 각 geoProbe는 [온체인](#onchain)에 등록되어 하나 이상의 상위 DZD에 연결됩니다. 기여자 문서는 [Geoprobe 배포](contribute-geolocation.md)를 참조하세요. +[Geolocation](#geolocation) 시스템에서 지연 시간 측정의 중개 역할을 하는 베어메탈 서버입니다. geoProbe는 [DZD](#dzd-doublezero-device)에서 ~1ms 이내에 위치하며, 상위 DZD로부터 서명된 LocationOffset을 수신하고, [TWAMP](#twamp-two-way-active-measurement-protocol), 서명된 TWAMP 또는 ICMP echo를 통해 대상 디바이스까지의 [RTT](#rtt-round-trip-time)를 측정합니다. 각 geoProbe는 [온체인](#onchain)에 등록되며 하나 이상의 상위 DZD에 연결됩니다. 기여자 문서는 [Geoprobe 배포](contribute-geolocation.md)를 참조하세요. ### LocationOffset -[DZD](#dzd-doublezero-device)의 지리적 위치(위도 및 경도)와 엔티티 간(DZD↔Probe 또는 Probe↔Target)의 지연 시간 관계 체인을 포함하는 서명된 데이터 구조입니다. LocationOffset은 Ed25519로 서명되며 측정 체인을 통해 UDP로 전송됩니다. 복합 오프셋에는 이전 측정에 대한 참조가 포함되어 감사 가능한 추적 경로를 생성합니다. +[DZD](#dzd-doublezero-device)의 지리적 위치(위도 및 경도)와 엔티티 간(DZD↔Probe 또는 Probe↔Target)의 지연 시간 관계 체인을 포함하는 서명된 데이터 구조입니다. LocationOffset은 Ed25519로 서명되며 측정 체인을 통해 UDP로 전송됩니다. 복합 오프셋은 이전 측정에 대한 참조를 포함하여 감사 가능한 추적 경로를 생성합니다. --- ## 블록체인 및 키 ### Onchain -DoubleZero 컨텍스트에서 온체인은 DoubleZero 레저에 기록되는 데이터 및 작업을 의미합니다. 디바이스 및 링크 구성이 중앙 집중식 관리 시스템에 존재하는 기존 네트워크와 달리, DoubleZero는 디바이스 등록, 링크 구성 및 텔레메트리 제출을 온체인에 기록하여 모든 참여자가 네트워크 상태를 투명하고 검증 가능하게 합니다. +DoubleZero 맥락에서 온체인은 DoubleZero 원장에 기록된 데이터 및 작업을 의미합니다. 디바이스 및 링크 구성이 중앙 집중식 관리 시스템에 존재하는 기존 네트워크와 달리, DoubleZero는 디바이스 등록, 링크 구성 및 텔레메트리 제출을 온체인에 기록하여 네트워크 상태를 모든 참여자가 투명하고 검증 가능하게 합니다. ### Service Key -CLI 작업을 인증하는 데 사용되는 암호화 키 쌍입니다. DoubleZero 스마트 컨트랙트와 상호 작용하기 위한 기여자 ID입니다. `~/.config/solana/id.json`에 저장됩니다. +CLI 작업을 인증하는 데 사용되는 암호화 키 쌍입니다. DoubleZero 스마트 컨트랙트와 상호작용하기 위한 기여자 ID입니다. `~/.config/solana/id.json`에 저장됩니다. ### Metrics Publisher Key -[Telemetry Agent](#telemetry-agent)가 블록체인에 메트릭 제출을 서명하는 데 사용하는 암호화 키 쌍입니다. 보안 격리를 위해 서비스 키와 분리되어 있습니다. `~/.config/doublezero/metrics-publisher.json`에 저장됩니다. +[Telemetry Agent](#telemetry-agent)가 블록체인에 대한 메트릭 제출에 서명하는 데 사용하는 암호화 키 쌍입니다. 보안 격리를 위해 서비스 키와 분리되어 있습니다. `~/.config/doublezero/metrics-publisher.json`에 저장됩니다. + +### Rewards Manager Key +기여자의 보상이 지급되는 위치를 제어하는 암호화 키 쌍입니다. 수신 지갑 목록의 변경에 서명하지만 보상 자체를 보유하지는 않습니다. [DZF](#dzf-doublezero-foundation)에 의해 기여자의 [Service Key](#service-key)에 대해 등록됩니다. [보상 관리](contribute-rewards.md)를 참조하세요. --- ## 하드웨어 및 소프트웨어 ### EOS (Extensible Operating System) -DZD 스위치에서 실행되는 Arista의 네트워크 운영 체제입니다. 기여자는 [Config Agent](#config-agent)와 [Telemetry Agent](#telemetry-agent)를 EOS 확장 기능으로 설치합니다. +DZD 스위치에서 실행되는 Arista의 네트워크 운영 체제입니다. 기여자는 [Config Agent](#config-agent) 및 [Telemetry Agent](#telemetry-agent)를 EOS 확장으로 설치합니다. ### EOS Extension Arista EOS 스위치에 설치할 수 있는 소프트웨어 패키지입니다. DZ 에이전트는 `.rpm` 파일로 배포되며 `extension` 명령을 통해 설치됩니다. \ No newline at end of file diff --git a/docs/glossary.pt.md b/docs/glossary.pt.md index 796531f..dd93760 100644 --- a/docs/glossary.pt.md +++ b/docs/glossary.pt.md @@ -1,10 +1,10 @@ --- -description: Definições da terminologia específica do DoubleZero usada ao longo da documentação. +description: Definições da terminologia específica do DoubleZero utilizada ao longo da documentação. --- # Glossário -Esta página define a terminologia específica do DoubleZero usada ao longo da documentação. +Esta página define a terminologia específica do DoubleZero utilizada ao longo da documentação. --- @@ -14,20 +14,20 @@ Esta página define a terminologia específica do DoubleZero usada ao longo da d O hardware físico de comutação de rede que termina os links DoubleZero e executa o software DoubleZero Agent. Os DZDs são implantados em data centers e fornecem serviços de roteamento, processamento de pacotes e conectividade de usuários. Cada DZD requer [especificações de hardware](contribute.md#dzd-network-hardware) específicas e executa tanto o [Config Agent](#config-agent) quanto o [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Pontos de interconexão na rede mesh onde diferentes links de [contribuidores](#contributor) são interligados. Os DZXs estão localizados em grandes áreas metropolitanas (ex.: NYC, LON, TYO) onde ocorrem interseções de rede. Os contribuidores de rede devem conectar seus links à malha DoubleZero mais ampla no DZX mais próximo. Conceito similar a um Internet Exchange (IX). +Pontos de interconexão na rede mesh onde os links de diferentes [contribuidores](#contributor) são interligados. Os DZXs estão localizados em grandes áreas metropolitanas (ex.: NYC, LON, TYO) onde ocorrem interseções de rede. Os contribuidores da rede devem fazer a conexão cruzada de seus links na malha mais ampla do DoubleZero no DZX mais próximo. Conceito similar a um Internet Exchange (IX). ### WAN Link -Um link de Rede de Longa Distância (Wide Area Network) entre dois [DZDs](#dzd-doublezero-device) operados pelo **mesmo** contribuidor. Os WAN links fornecem conectividade de backbone dentro da infraestrutura de um único contribuidor. +Um link de Rede de Longa Distância (Wide Area Network) entre dois [DZDs](#dzd-doublezero-device) operados pelo **mesmo** contribuidor. Os links WAN fornecem conectividade de backbone dentro da infraestrutura de um único contribuidor. ### DZX Link -Um link entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, estabelecido em um [DZX](#dzx-doublezero-exchange). Os DZX links requerem aceitação explícita de ambas as partes. +Um link entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, estabelecido em um [DZX](#dzx-doublezero-exchange). Os links DZX requerem aceitação explícita de ambas as partes. ### DZ Prefix -Alocações de endereço IP em formato CIDR atribuídas a um [DZD](#dzd-doublezero-device) para endereçamento de rede overlay. Especificado durante a [criação do dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando o parâmetro `--dz-prefixes`. +Alocações de endereços IP no formato CIDR atribuídas a um [DZD](#dzd-doublezero-device) para endereçamento da rede overlay. Especificado durante a [criação do dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando o parâmetro `--dz-prefixes`. --- -## Tipos de Dispositivo +## Tipos de Dispositivos ### Edge Device Um [DZD](#dzd-doublezero-device) que fornece conectividade de usuários à rede DoubleZero. Os dispositivos edge utilizam interfaces [CYOA](#cyoa-choose-your-own-adventure) para terminar usuários (validadores, operadores RPC) e conectá-los à rede. @@ -46,55 +46,55 @@ Um [DZD](#dzd-doublezero-device) que combina as funcionalidades de [edge](#edge- Tipos de interface que permitem aos [contribuidores](#contributor) registrar opções de conectividade para que os usuários se conectem à rede DoubleZero. As interfaces CYOA incluem vários métodos como [DIA](#dia-direct-internet-access), túneis GRE e peering privado. Consulte [Criando Interfaces CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) para detalhes de configuração. ### DIA (Direct Internet Access) -Um termo padrão de rede para conectividade fornecida pela internet pública. No DoubleZero, DIA é um tipo de interface [CYOA](#cyoa-choose-your-own-adventure) onde os usuários (validadores, operadores RPC) se conectam a um [DZD](#dzd-doublezero-device) por meio de sua conexão de internet existente. +Um termo padrão de redes para conectividade fornecida pela internet pública. No DoubleZero, DIA é um tipo de interface [CYOA](#cyoa-choose-your-own-adventure) onde os usuários (validadores, operadores RPC) se conectam a um [DZD](#dzd-doublezero-device) através de sua conexão de internet existente. ### IBRL (Increase Bandwidth Reduce Latency) -Um modo de conexão que permite que validadores e nós RPC se conectem ao DoubleZero sem reiniciar seus clientes blockchain. O IBRL usa o endereço IP público existente e estabelece um túnel overlay para o [DZD](#dzd-doublezero-device) mais próximo. Consulte [Conexão Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instruções de configuração. +Um modo de conexão que permite que validadores e nós RPC se conectem ao DoubleZero sem reiniciar seus clientes blockchain. O IBRL utiliza o endereço IP público existente e estabelece um túnel overlay para o [DZD](#dzd-doublezero-device) mais próximo. Consulte [Conexão Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instruções de configuração. ### Multicast -Um método de entrega de pacotes de um-para-muitos suportado pelo DoubleZero. O modo multicast tem duas funções: **publisher** (envia pacotes pela rede) e **subscriber** (recebe pacotes do publisher). Usado por equipes de desenvolvimento para distribuição eficiente de dados. Consulte [Outra Conexão Multicast](Other%20Multicast%20Connection.md) para detalhes de conexão. +Um método de entrega de pacotes de um-para-muitos suportado pelo DoubleZero. O modo multicast possui dois papéis: **publisher** (envia pacotes pela rede) e **subscriber** (recebe pacotes do publisher). Utilizado por equipes de desenvolvimento para distribuição eficiente de dados. Consulte [Outra Conexão Multicast](Other%20Multicast%20Connection.md) para detalhes de conexão. --- ## Componentes de Software ### doublezerod -O serviço daemon do DoubleZero que executa nos servidores dos usuários (validadores, nós RPC). Ele gerencia a conexão com a rede DoubleZero, lida com o estabelecimento de túneis e mantém a conectividade com os [DZDs](#dzd-doublezero-device). Configurado via systemd e controlado através da CLI [`doublezero`](#doublezero-cli). +O serviço daemon do DoubleZero que é executado nos servidores dos usuários (validadores, nós RPC). Ele gerencia a conexão com a rede DoubleZero, lida com o estabelecimento de túneis e mantém a conectividade com os [DZDs](#dzd-doublezero-device). Configurado via systemd e controlado através da CLI [`doublezero`](#doublezero-cli). ### doublezero (CLI) -A interface de linha de comando para interagir com a rede DoubleZero. Usada para conectar, gerenciar identidades, verificar status e operações administrativas. Comunica-se com o daemon [`doublezerod`](#doublezerod). +A interface de linha de comando para interagir com a rede DoubleZero. Utilizada para conectar, gerenciar identidades, verificar status e operações administrativas. Comunica-se com o daemon [`doublezerod`](#doublezerod). ### Config Agent -Agente de software executado nos [DZDs](#dzd-doublezero-device) que gerencia a configuração do dispositivo. Lê a configuração do serviço [Controller](#controller) e aplica as alterações ao dispositivo. Consulte [Instalação do Config Agent](contribute-provisioning.md#step-44-install-config-agent) para configuração. +Agente de software executado nos [DZDs](#dzd-doublezero-device) que gerencia a configuração do dispositivo. Lê a configuração do serviço [Controller](#controller) e aplica as alterações no dispositivo. Consulte [Instalação do Config Agent](contribute-provisioning.md#step-44-install-config-agent) para configuração. ### Telemetry Agent -Agente de software executado nos [DZDs](#dzd-doublezero-device) que coleta métricas de desempenho (latência, jitter, perda de pacotes) e as envia ao ledger do DoubleZero. Consulte [Instalação do Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) para configuração. +Agente de software executado nos [DZDs](#dzd-doublezero-device) que coleta métricas de desempenho (latência, jitter, perda de pacotes) e as submete ao ledger do DoubleZero. Consulte [Instalação do Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) para configuração. ### Controller Um serviço que fornece configuração aos agentes dos [DZDs](#dzd-doublezero-device). O Controller deriva as configurações dos dispositivos a partir do estado [onchain](#onchain) no ledger do DoubleZero. --- -## Estados de Link +## Estados dos Links ### Activated O estado operacional normal de um link. O tráfego flui pelo link e ele participa das decisões de roteamento. ### Soft-Drained -Um estado de manutenção onde o tráfego será desencorajado em um link específico. Usado para janelas de manutenção gradual. Pode transicionar para [activated](#activated) ou [hard-drained](#hard-drained). +Um estado de manutenção onde o tráfego será desencorajado em um link específico. Utilizado para janelas de manutenção gradual. Pode transicionar para [activated](#activated) ou [hard-drained](#hard-drained). ### Hard-Drained -Um estado de manutenção onde o link é completamente removido do serviço. Nenhum tráfego flui pelo link. Deve transicionar para [soft-drained](#soft-drained) antes de retornar a [activated](#activated). +Um estado de manutenção onde o link é completamente removido do serviço. Nenhum tráfego flui pelo link. Deve transicionar para [soft-drained](#soft-drained) antes de retornar ao estado [activated](#activated). --- -## Organizações e Tokens +## Organizações & Tokens ### DZF (DoubleZero Foundation) -A DoubleZero Foundation é uma empresa-fundação sem membros, sem fins lucrativos, das Ilhas Cayman, que foi formada para apoiar o desenvolvimento, descentralização, segurança e adoção da rede DoubleZero. +A DoubleZero Foundation é uma empresa-fundação sem membros, sem fins lucrativos, das Ilhas Cayman, formada para apoiar o desenvolvimento, descentralização, segurança e adoção da rede DoubleZero. ### 2Z Token -O token nativo da rede DoubleZero. Usado para pagar taxas de validadores e distribuído como recompensas aos [contribuidores](#contributor). Os validadores podem pagar taxas em 2Z por meio de um programa de swap onchain. Consulte [Trocando SOL por 2Z](Swapping-sol-to-2z.md). +O token nativo da rede DoubleZero. Utilizado para pagamento de taxas de validadores e distribuído como recompensas aos [contribuidores](#contributor). Validadores podem pagar taxas em 2Z através de um programa de swap onchain. Consulte [Trocando SOL por 2Z](Swapping-sol-to-2z.md). ### Contributor Um provedor de infraestrutura de rede que contribui com largura de banda e hardware para a rede DoubleZero. Os contribuidores operam [DZDs](#dzd-doublezero-device), fornecem links [WAN](#wan-link) e [DZX](#dzx-link), e recebem incentivos em tokens [2Z](#2z-token) por sua contribuição. Consulte a [Documentação para Contribuidores](contribute-overview.md) para começar. @@ -104,70 +104,73 @@ Um provedor de infraestrutura de rede que contribui com largura de banda e hardw ## Conceitos de Rede ### MTU (Maximum Transmission Unit) -O maior tamanho de pacote (em bytes) que pode ser transmitido por um link de rede. Os WAN links do DoubleZero tipicamente usam MTU 9000 (jumbo frames) para eficiência. +O maior tamanho de pacote (em bytes) que pode ser transmitido por um link de rede. Os links WAN do DoubleZero tipicamente utilizam MTU 9000 (jumbo frames) para eficiência. ### VRF (Virtual Routing and Forwarding) -Uma tecnologia que permite que múltiplas tabelas de roteamento isoladas existam no mesmo roteador físico. Os contribuidores frequentemente usam um VRF de gerenciamento separado para isolar o tráfego de gerenciamento do switch do tráfego de produção. +Uma tecnologia que permite que múltiplas tabelas de roteamento isoladas existam no mesmo roteador físico. Os contribuidores frequentemente utilizam um VRF de gerenciamento separado para isolar o tráfego de gerenciamento do switch do tráfego de produção. ### GRE (Generic Routing Encapsulation) -Um protocolo de tunelamento que encapsula pacotes de rede dentro de pacotes IP. Usado por conexões [IBRL](#ibrl-increase-bandwidth-reduce-latency) e [CYOA](#cyoa-choose-your-own-adventure) para criar túneis overlay entre usuários e DZDs. +Um protocolo de tunelamento que encapsula pacotes de rede dentro de pacotes IP. Utilizado por conexões [IBRL](#ibrl-increase-bandwidth-reduce-latency) e [CYOA](#cyoa-choose-your-own-adventure) para criar túneis overlay entre usuários e DZDs. ### BGP (Border Gateway Protocol) -O protocolo de roteamento usado para trocar informações de roteamento entre redes na internet. O DoubleZero usa BGP internamente com ASN 65342. +O protocolo de roteamento utilizado para troca de informações de roteamento entre redes na internet. O DoubleZero utiliza BGP internamente com ASN 65342. ### ASN (Autonomous System Number) -Um identificador único atribuído a uma rede para roteamento BGP. Todos os dispositivos DoubleZero usam **ASN 65342** para o processo BGP interno. +Um identificador único atribuído a uma rede para roteamento BGP. Todos os dispositivos DoubleZero utilizam **ASN 65342** para o processo BGP interno. ### Loopback Interface -Uma interface de rede virtual em um roteador/switch usada para fins de gerenciamento e roteamento. Os DZDs usam Loopback255 (VPNv4) e Loopback256 (IPv4) para roteamento interno. +Uma interface de rede virtual em um roteador/switch utilizada para fins de gerenciamento e roteamento. Os DZDs utilizam Loopback255 (VPNv4) e Loopback256 (IPv4) para roteamento interno. ### CIDR (Classless Inter-Domain Routing) -Uma notação para especificar intervalos de endereços IP. O formato é `IP/prefix-length` onde o comprimento do prefixo indica o tamanho da rede (ex.: `/29` = 8 endereços, `/24` = 256 endereços). +Uma notação para especificar faixas de endereços IP. O formato é `IP/prefix-length` onde o comprimento do prefixo indica o tamanho da rede (ex.: `/29` = 8 endereços, `/24` = 256 endereços). ### Jitter Variação na latência dos pacotes ao longo do tempo. Baixo jitter é crítico para aplicações em tempo real. ### RTT (Round-Trip Time) -O tempo para um pacote viajar da origem ao destino e retornar. Usado para medir a latência de rede entre dispositivos. +O tempo para um pacote viajar da origem ao destino e retornar. Utilizado para medir a latência de rede entre dispositivos. ### TWAMP (Two-Way Active Measurement Protocol) -Um protocolo para medir métricas de desempenho de rede como latência e perda de pacotes. O [Telemetry Agent](#telemetry-agent) usa TWAMP para coletar métricas entre DZDs. +Um protocolo para medir métricas de desempenho de rede como latência e perda de pacotes. O [Telemetry Agent](#telemetry-agent) utiliza TWAMP para coletar métricas entre DZDs. ### IS-IS (Intermediate System to Intermediate System) -Um protocolo de roteamento de estado de link usado internamente pela rede DoubleZero. As métricas IS-IS são ajustadas durante operações de [drenagem de link](#soft-drained). +Um protocolo de roteamento de estado de link utilizado internamente pela rede DoubleZero. As métricas IS-IS são ajustadas durante operações de [drenagem de link](#soft-drained). --- ## Geolocalização -### Geolocation -Um serviço do DoubleZero que verifica a localização física de dispositivos usando medições de latência. Medições de [RTT](#rtt-round-trip-time) entre infraestrutura de localização conhecida ([DZDs](#dzd-doublezero-device)) e dispositivos-alvo fornecem prova assinada criptograficamente de que um dispositivo está dentro de uma certa distância de um ponto de referência. O registro onchain das medições está planejado para uma versão futura. Consulte [Geolocalização](geolocation.md) para documentação do usuário. +### Geolocalização +Um serviço do DoubleZero que verifica a localização física dos dispositivos utilizando medições de latência. Medições de [RTT](#rtt-round-trip-time) entre infraestrutura de localização conhecida ([DZDs](#dzd-doublezero-device)) e dispositivos-alvo fornecem prova assinada criptograficamente de que um dispositivo está dentro de uma certa distância de um ponto de referência. O registro onchain das medições está planejado para uma versão futura. Consulte [Geolocalização](geolocation.md) para documentação do usuário. ### geoProbe -Um servidor bare metal que atua como intermediário para medições de latência no sistema de [Geolocalização](#geolocation). Os geoProbes estão localizados a ~1ms de um [DZD](#dzd-doublezero-device), recebem LocationOffsets assinados dos DZDs pais e medem [RTT](#rtt-round-trip-time) para dispositivos-alvo via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP assinado ou ICMP echo. Cada geoProbe é registrado [onchain](#onchain) e vinculado a um ou mais DZDs pais. Consulte [Implantação de Geoprobe](contribute-geolocation.md) para documentação de contribuidores. +Um servidor bare metal que atua como intermediário para medições de latência no sistema de [Geolocalização](#geolocalização). Os geoProbes estão localizados a ~1ms de um [DZD](#dzd-doublezero-device), recebem LocationOffsets assinados dos DZDs pai e medem [RTT](#rtt-round-trip-time) para dispositivos-alvo via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP assinado ou ICMP echo. Cada geoProbe é registrado [onchain](#onchain) e vinculado a um ou mais DZDs pai. Consulte [Implantação de Geoprobe](contribute-geolocation.md) para documentação de contribuidores. ### LocationOffset -Uma estrutura de dados assinada contendo a localização geográfica de um [DZD](#dzd-doublezero-device) (latitude e longitude) e uma cadeia de relações de latência entre entidades (DZD↔Probe ou Probe↔Target). Os LocationOffsets são assinados com Ed25519 e enviados via UDP pela cadeia de medição. Offsets compostos incluem referências a medições anteriores, criando uma trilha auditável. +Uma estrutura de dados assinada contendo a localização geográfica de um [DZD](#dzd-doublezero-device) (latitude e longitude) e uma cadeia de relações de latência entre entidades (DZD↔Probe ou Probe↔Alvo). Os LocationOffsets são assinados com Ed25519 e enviados via UDP através da cadeia de medição. Offsets compostos incluem referências a medições anteriores, criando uma trilha auditável. --- -## Blockchain e Chaves +## Blockchain & Chaves ### Onchain -No contexto do DoubleZero, onchain refere-se a dados e operações registrados no ledger do DoubleZero. Diferentemente das redes tradicionais onde configurações de dispositivos e links residem em sistemas de gerenciamento centralizados, o DoubleZero registra registros de dispositivos, configurações de links e submissões de telemetria onchain — tornando o estado da rede transparente e verificável por todos os participantes. +No contexto do DoubleZero, onchain refere-se a dados e operações registrados no ledger do DoubleZero. Diferente de redes tradicionais onde as configurações de dispositivos e links residem em sistemas de gerenciamento centralizados, o DoubleZero registra registros de dispositivos, configurações de links e submissões de telemetria onchain — tornando o estado da rede transparente e verificável por todos os participantes. ### Service Key -Um par de chaves criptográficas usado para autenticar operações da CLI. Esta é a sua identidade de contribuidor para interagir com o smart contract do DoubleZero. Armazenada em `~/.config/solana/id.json`. +Um par de chaves criptográficas utilizado para autenticar operações da CLI. Esta é sua identidade de contribuidor para interagir com o smart contract do DoubleZero. Armazenada em `~/.config/solana/id.json`. ### Metrics Publisher Key -Um par de chaves criptográficas usado pelo [Telemetry Agent](#telemetry-agent) para assinar submissões de métricas ao blockchain. Separada da service key para isolamento de segurança. Armazenada em `~/.config/doublezero/metrics-publisher.json`. +Um par de chaves criptográficas utilizado pelo [Telemetry Agent](#telemetry-agent) para assinar submissões de métricas na blockchain. Separada da service key para isolamento de segurança. Armazenada em `~/.config/doublezero/metrics-publisher.json`. + +### Rewards Manager Key +Um par de chaves criptográficas que controla para onde as recompensas de um contribuidor são pagas. Ele assina alterações na lista de carteiras destinatárias, mas nunca detém recompensas em si. Registrada contra a [Service Key](#service-key) do contribuidor pela [DZF](#dzf-doublezero-foundation). Consulte [Gerenciamento de Recompensas](contribute-rewards.md). --- -## Hardware e Software +## Hardware & Software ### EOS (Extensible Operating System) -O sistema operacional de rede da Arista que roda nos switches DZD. Os contribuidores instalam o [Config Agent](#config-agent) e o [Telemetry Agent](#telemetry-agent) como extensões EOS. +O sistema operacional de rede da Arista que é executado nos switches DZD. Os contribuidores instalam o [Config Agent](#config-agent) e o [Telemetry Agent](#telemetry-agent) como extensões EOS. ### EOS Extension Um pacote de software que pode ser instalado em switches Arista EOS. Os agentes DZ são distribuídos como arquivos `.rpm` e instalados via o comando `extension`. \ No newline at end of file diff --git a/docs/glossary.zh.md b/docs/glossary.zh.md index 7452def..f7b493a 100644 --- a/docs/glossary.zh.md +++ b/docs/glossary.zh.md @@ -1,28 +1,28 @@ --- -description: DoubleZero 文档中使用的特定术语定义。 +description: DoubleZero 文档中使用的专有术语定义。 --- # 术语表 -本页定义了文档中使用的 DoubleZero 特定术语。 +本页面定义了文档中使用的 DoubleZero 专有术语。 --- ## 网络基础设施 -### DZD（DoubleZero Device，DoubleZero 设备） +### DZD (DoubleZero Device) 终结 DoubleZero 链路并运行 DoubleZero Agent 软件的物理网络交换硬件。DZD 部署在数据中心，提供路由、数据包处理和用户连接服务。每个 DZD 需要满足特定的[硬件规格](contribute.md#dzd-network-hardware)，并同时运行 [Config Agent](#config-agent) 和 [Telemetry Agent](#telemetry-agent)。 -### DZX（DoubleZero Exchange，DoubleZero 交换点） -网状网络中的互联点，不同[贡献者](#contributor)的链路在此桥接。DZX 位于主要大都市区域（如纽约、伦敦、东京），即网络交汇处。网络贡献者必须在最近的 DZX 将其链路交叉连接到更广泛的 DoubleZero 网状网络中。概念上类似于互联网交换点（IX）。 +### DZX (DoubleZero Exchange) +网状网络中的互联点，不同[贡献者](#contributor)的链路在此处桥接在一起。DZX 位于主要大都市区域（例如纽约、伦敦、东京）中网络交汇的位置。网络贡献者必须将其链路在最近的 DZX 处交叉连接到更广泛的 DoubleZero 网状网络中。概念上类似于互联网交换点（IX）。 -### WAN Link（广域网链路） +### WAN Link 由**同一**贡献者运营的两个 [DZD](#dzd-doublezero-device) 之间的广域网链路。WAN 链路在单个贡献者的基础设施内提供骨干连接。 -### DZX Link（DZX 链路） -由**不同**贡献者运营的 [DZD](#dzd-doublezero-device) 之间在 [DZX](#dzx-doublezero-exchange) 处建立的链路。DZX 链路需要双方明确接受。 +### DZX Link +由**不同**贡献者运营的 [DZD](#dzd-doublezero-device) 之间的链路，在 [DZX](#dzx-doublezero-exchange) 处建立。DZX 链路需要双方明确接受。 -### DZ Prefix（DZ 前缀） +### DZ Prefix 以 CIDR 格式分配给 [DZD](#dzd-doublezero-device) 的 IP 地址，用于覆盖网络寻址。在[设备创建](contribute-provisioning.md#step-32-create-your-device-onchain)时通过 `--dz-prefixes` 参数指定。 --- @@ -30,47 +30,47 @@ description: DoubleZero 文档中使用的特定术语定义。 ## 设备类型 ### Edge Device（边缘设备） -为用户提供 DoubleZero 网络连接的 [DZD](#dzd-doublezero-device)。边缘设备利用 [CYOA](#cyoa-choose-your-own-adventure) 接口来终结用户（验证者、RPC 运营者）并将其连接到网络。 +为用户提供 DoubleZero 网络连接的 [DZD](#dzd-doublezero-device)。边缘设备利用 [CYOA](#cyoa-choose-your-own-adventure) 接口终结用户（验证者、RPC 运营者）并将其连接到网络。 ### Transit Device（中转设备） 在 DoubleZero 网络内提供骨干连接的 [DZD](#dzd-doublezero-device)。中转设备在 DZD 之间转发流量，但不直接终结用户连接。 ### Hybrid Device（混合设备） -同时具备[边缘](#edge-device)和[中转](#transit-device)功能的 [DZD](#dzd-doublezero-device)，既提供用户连接又提供骨干路由。 +同时具备[边缘](#edge-device)和[中转](#transit-device)功能的 [DZD](#dzd-doublezero-device)，既提供用户连接，又提供骨干路由。 --- ## 连接方式 -### CYOA（Choose Your Own Adventure，自选连接方式） -允许[贡献者](#contributor)注册连接选项的接口类型，供用户连接到 DoubleZero 网络。CYOA 接口包括 [DIA](#dia-direct-internet-access)、GRE 隧道和私有对等互联等多种方式。配置详情请参阅[创建 CYOA 接口](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)。 +### CYOA (Choose Your Own Adventure) +允许[贡献者](#contributor)注册连接选项的接口类型，供用户连接到 DoubleZero 网络。CYOA 接口包括 [DIA](#dia-direct-internet-access)、GRE 隧道和私有对等互联等多种方式。配置详情请参见[创建 CYOA 接口](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)。 -### DIA（Direct Internet Access，直接互联网接入） +### DIA (Direct Internet Access) 通过公共互联网提供连接的标准网络术语。在 DoubleZero 中，DIA 是一种 [CYOA](#cyoa-choose-your-own-adventure) 接口类型，用户（验证者、RPC 运营者）通过其现有的互联网连接接入 [DZD](#dzd-doublezero-device)。 -### IBRL（Increase Bandwidth Reduce Latency，增加带宽降低延迟） -一种连接模式，允许验证者和 RPC 节点无需重启区块链客户端即可连接到 DoubleZero。IBRL 使用现有的公网 IP 地址，并与最近的 [DZD](#dzd-doublezero-device) 建立覆盖隧道。设置说明请参阅[主网测试版连接](DZ%20Mainnet-beta%20Connection.md)。 +### IBRL (Increase Bandwidth Reduce Latency) +一种连接模式，允许验证者和 RPC 节点无需重启区块链客户端即可连接到 DoubleZero。IBRL 使用现有的公共 IP 地址，并与最近的 [DZD](#dzd-doublezero-device) 建立覆盖隧道。设置说明请参见[主网 Beta 版连接](DZ%20Mainnet-beta%20Connection.md)。 ### Multicast（组播） -DoubleZero 支持的一对多数据包传递方式。组播模式有两种角色：**发布者**（publisher，通过网络发送数据包）和**订阅者**（subscriber，从发布者接收数据包）。开发团队用于高效的数据分发。连接详情请参阅[其他组播连接](Other%20Multicast%20Connection.md)。 +DoubleZero 支持的一对多数据包传递方式。组播模式有两种角色：**发布者**（通过网络发送数据包）和**订阅者**（从发布者接收数据包）。开发团队用于高效的数据分发。连接详情请参见[其他组播连接](Other%20Multicast%20Connection.md)。 --- ## 软件组件 ### doublezerod -运行在用户服务器（验证者、RPC 节点）上的 DoubleZero 守护进程服务。它管理与 DoubleZero 网络的连接，处理隧道建立，并维持与 [DZD](#dzd-doublezero-device) 的连接。通过 systemd 配置，并通过 [`doublezero`](#doublezero-cli) CLI 控制。 +运行在用户服务器（验证者、RPC 节点）上的 DoubleZero 守护进程服务。它管理与 DoubleZero 网络的连接，处理隧道建立，并维护与 [DZD](#dzd-doublezero-device) 的连接。通过 systemd 配置，并通过 [`doublezero`](#doublezero-cli) CLI 控制。 ### doublezero (CLI) -与 DoubleZero 网络交互的命令行界面。用于连接、管理身份、检查状态和管理操作。与 [`doublezerod`](#doublezerod) 守护进程通信。 +用于与 DoubleZero 网络交互的命令行界面。用于连接、管理身份、检查状态和执行管理操作。与 [`doublezerod`](#doublezerod) 守护进程通信。 -### Config Agent（配置代理） -运行在 [DZD](#dzd-doublezero-device) 上的软件代理，管理设备配置。从 [Controller](#controller) 服务读取配置并将更改应用到设备。设置请参阅 [Config Agent 安装](contribute-provisioning.md#step-44-install-config-agent)。 +### Config Agent +运行在 [DZD](#dzd-doublezero-device) 上的软件代理，负责管理设备配置。从 [Controller](#controller) 服务读取配置并将更改应用到设备。设置请参见 [Config Agent 安装](contribute-provisioning.md#step-44-install-config-agent)。 -### Telemetry Agent（遥测代理） -运行在 [DZD](#dzd-doublezero-device) 上的软件代理，收集性能指标（延迟、抖动、丢包率）并提交到 DoubleZero 账本。设置请参阅 [Telemetry Agent 安装](contribute-provisioning.md#step-45-install-telemetry-agent)。 +### Telemetry Agent +运行在 [DZD](#dzd-doublezero-device) 上的软件代理，收集性能指标（延迟、抖动、丢包率）并提交到 DoubleZero 账本。设置请参见 [Telemetry Agent 安装](contribute-provisioning.md#step-45-install-telemetry-agent)。 -### Controller（控制器） +### Controller 为 [DZD](#dzd-doublezero-device) 代理提供配置的服务。Controller 从 DoubleZero 账本上的[链上](#onchain)状态派生设备配置。 --- @@ -84,90 +84,93 @@ DoubleZero 支持的一对多数据包传递方式。组播模式有两种角色 一种维护状态，流量将被引导远离特定链路。用于优雅的维护窗口。可以转换为[已激活](#activated)或[硬排空](#hard-drained)状态。 ### Hard-Drained（硬排空） -一种维护状态，链路完全从服务中移除。没有流量通过该链路。必须先转换为[软排空](#soft-drained)状态才能恢复到[已激活](#activated)状态。 +一种维护状态，链路完全从服务中移除。没有流量通过该链路。必须先转换为[软排空](#soft-drained)状态，然后才能恢复为[已激活](#activated)状态。 --- ## 组织与代币 -### DZF（DoubleZero Foundation，DoubleZero 基金会） -DoubleZero 基金会是一家无会员制的开曼群岛非营利性基金会公司，成立旨在支持 DoubleZero 网络的开发、去中心化、安全性和推广。 +### DZF (DoubleZero Foundation) +DoubleZero Foundation 是一家无会员的开曼群岛非营利基金会公司，成立旨在支持 DoubleZero 网络的开发、去中心化、安全性和推广。 -### 2Z Token（2Z 代币） -DoubleZero 网络的原生代币。用于支付验证者费用并作为奖励分发给[贡献者](#contributor)。验证者可以通过链上兑换程序使用 2Z 支付费用。请参阅[将 SOL 兑换为 2Z](Swapping-sol-to-2z.md)。 +### 2Z Token +DoubleZero 网络的原生代币。用于支付验证者费用，并作为奖励分发给[贡献者](#contributor)。验证者可以通过链上兑换程序以 2Z 支付费用。请参见[将 SOL 兑换为 2Z](Swapping-sol-to-2z.md)。 ### Contributor（贡献者） -为 DoubleZero 网络贡献带宽和硬件的网络基础设施提供者。贡献者运营 [DZD](#dzd-doublezero-device)，提供 [WAN](#wan-link) 和 [DZX](#dzx-link) 链路，并因其贡献获得 [2Z](#2z-token) 代币激励。入门请参阅[贡献者文档](contribute-overview.md)。 +为 DoubleZero 网络贡献带宽和硬件的网络基础设施提供者。贡献者运营 [DZD](#dzd-doublezero-device)，提供 [WAN](#wan-link) 和 [DZX](#dzx-link) 链路，并因其贡献获得 [2Z](#2z-token) 代币激励。入门请参见[贡献者文档](contribute-overview.md)。 --- ## 网络概念 -### MTU（Maximum Transmission Unit，最大传输单元） +### MTU (Maximum Transmission Unit) 可以通过网络链路传输的最大数据包大小（以字节为单位）。DoubleZero WAN 链路通常使用 MTU 9000（巨型帧）以提高效率。 -### VRF（Virtual Routing and Forwarding，虚拟路由和转发） -一种允许同一物理路由器上存在多个隔离路由表的技术。贡献者通常使用单独的管理 VRF 将交换机管理流量与生产流量隔离。 +### VRF (Virtual Routing and Forwarding) +一种允许多个隔离路由表共存于同一物理路由器上的技术。贡献者通常使用单独的管理 VRF 将交换机管理流量与生产流量隔离。 -### GRE（Generic Routing Encapsulation，通用路由封装） -一种将网络数据包封装在 IP 数据包内的隧道协议。被 [IBRL](#ibrl-increase-bandwidth-reduce-latency) 和 [CYOA](#cyoa-choose-your-own-adventure) 连接用于在用户和 DZD 之间创建覆盖隧道。 +### GRE (Generic Routing Encapsulation) +一种将网络数据包封装在 IP 数据包内的隧道协议。[IBRL](#ibrl-increase-bandwidth-reduce-latency) 和 [CYOA](#cyoa-choose-your-own-adventure) 连接使用 GRE 在用户和 DZD 之间创建覆盖隧道。 -### BGP（Border Gateway Protocol，边界网关协议） +### BGP (Border Gateway Protocol) 用于在互联网上的网络之间交换路由信息的路由协议。DoubleZero 内部使用 BGP，ASN 为 65342。 -### ASN（Autonomous System Number，自治系统号） +### ASN (Autonomous System Number) 分配给网络用于 BGP 路由的唯一标识符。所有 DoubleZero 设备的内部 BGP 进程使用 **ASN 65342**。 ### Loopback Interface（环回接口） -路由器/交换机上用于管理和路由目的的虚拟网络接口。DZD 使用 Loopback255（VPNv4）和 Loopback256（IPv4）进行内部路由。 +路由器/交换机上用于管理和路由目的的虚拟网络接口。DZD 使用 Loopback255 (VPNv4) 和 Loopback256 (IPv4) 进行内部路由。 -### CIDR（Classless Inter-Domain Routing，无类别域间路由） +### CIDR (Classless Inter-Domain Routing) 用于指定 IP 地址范围的表示法。格式为 `IP/prefix-length`，其中前缀长度表示网络大小（例如，`/29` = 8 个地址，`/24` = 256 个地址）。 ### Jitter（抖动） 数据包延迟随时间的变化。低抖动对实时应用至关重要。 -### RTT（Round-Trip Time，往返时间） +### RTT (Round-Trip Time) 数据包从源到目的地再返回所需的时间。用于测量设备之间的网络延迟。 -### TWAMP（Two-Way Active Measurement Protocol，双向主动测量协议） +### TWAMP (Two-Way Active Measurement Protocol) 一种用于测量延迟和丢包率等网络性能指标的协议。[Telemetry Agent](#telemetry-agent) 使用 TWAMP 在 DZD 之间收集指标。 -### IS-IS（Intermediate System to Intermediate System，中间系统到中间系统） -DoubleZero 网络内部使用的链路状态路由协议。在[链路排空](#soft-drained)操作期间会调整 IS-IS 指标。 +### IS-IS (Intermediate System to Intermediate System) +DoubleZero 网络内部使用的链路状态路由协议。在[链路排空](#soft-drained)操作期间会调整 IS-IS 度量值。 --- ## 地理定位 ### Geolocation（地理定位） -DoubleZero 的一项服务，通过延迟测量验证设备的物理位置。已知位置的基础设施（[DZD](#dzd-doublezero-device)）与目标设备之间的 [RTT](#rtt-round-trip-time) 测量提供加密签名的证明，证明设备在参考点的一定距离范围内。测量数据的链上记录计划在未来版本中实现。用户文档请参阅[地理定位](geolocation.md)。 +DoubleZero 的一项服务，通过延迟测量验证设备的物理位置。已知位置的基础设施（[DZD](#dzd-doublezero-device)）与目标设备之间的 [RTT](#rtt-round-trip-time) 测量提供经过加密签名的证明，证明设备位于参考点的一定距离内。链上记录测量数据计划在未来版本中实现。用户文档请参见[地理定位](geolocation.md)。 -### geoProbe（地理探针） -在[地理定位](#geolocation)系统中充当延迟测量中介的裸机服务器。geoProbe 位于 [DZD](#dzd-doublezero-device) ~1ms 范围内，从父级 DZD 接收签名的 LocationOffset，并通过 [TWAMP](#twamp-two-way-active-measurement-protocol)、签名 TWAMP 或 ICMP echo 测量到目标设备的 [RTT](#rtt-round-trip-time)。每个 geoProbe 在[链上](#onchain)注册并关联到一个或多个父级 DZD。贡献者文档请参阅 [Geoprobe 部署](contribute-geolocation.md)。 +### geoProbe +在[地理定位](#geolocation)系统中充当延迟测量中介的裸金属服务器。geoProbe 位于距 [DZD](#dzd-doublezero-device) 约 1ms 以内的位置，从父级 DZD 接收签名的 LocationOffset，并通过 [TWAMP](#twamp-two-way-active-measurement-protocol)、签名 TWAMP 或 ICMP echo 测量到目标设备的 [RTT](#rtt-round-trip-time)。每个 geoProbe 在[链上](#onchain)注册并关联到一个或多个父级 DZD。贡献者文档请参见 [Geoprobe 部署](contribute-geolocation.md)。 -### LocationOffset（位置偏移） -一种签名数据结构，包含 [DZD](#dzd-doublezero-device) 的地理位置（经纬度）以及实体之间的延迟关系链（DZD↔Probe 或 Probe↔Target）。LocationOffset 使用 Ed25519 签名，并通过 UDP 在测量链中发送。组合偏移包含对先前测量的引用，形成可审计的追踪链。 +### LocationOffset +一种签名数据结构，包含 [DZD](#dzd-doublezero-device) 的地理位置（经纬度）以及实体之间的延迟关系链（DZD↔Probe 或 Probe↔Target）。LocationOffset 使用 Ed25519 签名，并通过 UDP 在测量链中发送。复合偏移量包含对先前测量的引用，形成可审计的追踪链。 --- ## 区块链与密钥 ### Onchain（链上） -在 DoubleZero 的语境中，链上指的是记录在 DoubleZero 账本上的数据和操作。与传统网络中设备和链路配置存储在集中管理系统中不同，DoubleZero 将设备注册、链路配置和遥测提交记录在链上——使网络状态对所有参与者透明且可验证。 +在 DoubleZero 语境中，链上指记录在 DoubleZero 账本上的数据和操作。与传统网络中设备和链路配置存储在集中管理系统中不同，DoubleZero 将设备注册、链路配置和遥测提交记录在链上——使网络状态对所有参与者透明且可验证。 ### Service Key（服务密钥） -用于验证 CLI 操作的加密密钥对。这是您与 DoubleZero 智能合约交互的贡献者身份。存储在 `~/.config/solana/id.json`。 +用于验证 CLI 操作的加密密钥对。这是您与 DoubleZero 智能合约交互时的贡献者身份。存储在 `~/.config/solana/id.json`。 ### Metrics Publisher Key（指标发布密钥） -[Telemetry Agent](#telemetry-agent) 用于签名向区块链提交指标的加密密钥对。出于安全隔离的目的，与服务密钥分开。存储在 `~/.config/doublezero/metrics-publisher.json`。 +[Telemetry Agent](#telemetry-agent) 用于签名提交到区块链的指标数据的加密密钥对。出于安全隔离的目的，与服务密钥分开。存储在 `~/.config/doublezero/metrics-publisher.json`。 + +### Rewards Manager Key（奖励管理密钥） +控制贡献者奖励支付去向的加密密钥对。它签名对接收钱包列表的更改，但自身从不持有奖励。由 [DZF](#dzf-doublezero-foundation) 针对贡献者的 [Service Key](#service-key) 进行注册。请参见[奖励管理](contribute-rewards.md)。 --- ## 硬件与软件 -### EOS（Extensible Operating System，可扩展操作系统） -Arista 的网络操作系统，运行在 DZD 交换机上。贡献者将 [Config Agent](#config-agent) 和 [Telemetry Agent](#telemetry-agent) 作为 EOS 扩展安装。 +### EOS (Extensible Operating System) +Arista 的网络操作系统，运行在 DZD 交换机上。贡献者将 [Config Agent](#config-agent) 和 [Telemetry Agent](#telemetry-agent) 作为 EOS 扩展进行安装。 -### EOS Extension（EOS 扩展） +### EOS Extension 可以安装在 Arista EOS 交换机上的软件包。DZ 代理以 `.rpm` 文件形式分发，通过 `extension` 命令安装。 \ No newline at end of file From d2a708b315886db1b48b7071d8dacf4f51c16b4d Mon Sep 17 00:00:00 2001 From: Thijs van Emmerik Date: Thu, 10 Sep 2026 09:39:10 +0000 Subject: [PATCH 3/4] docs: trim rewards to a setup step, split checklist ownership, move link monitoring to the data portal --- docs/contribute-overview.md | 37 ++-- docs/contribute-provisioning.md | 100 +++++------ docs/contribute-rewards.es.md | 292 -------------------------------- docs/contribute-rewards.fr.md | 292 -------------------------------- docs/contribute-rewards.it.md | 292 -------------------------------- docs/contribute-rewards.ja.md | 292 -------------------------------- docs/contribute-rewards.ko.md | 292 -------------------------------- docs/contribute-rewards.md | 292 -------------------------------- docs/contribute-rewards.pt.md | 292 -------------------------------- docs/contribute-rewards.zh.md | 292 -------------------------------- docs/glossary.md | 2 +- mkdocs.yml | 1 - 12 files changed, 68 insertions(+), 2408 deletions(-) delete mode 100644 docs/contribute-rewards.es.md delete mode 100644 docs/contribute-rewards.fr.md delete mode 100644 docs/contribute-rewards.it.md delete mode 100644 docs/contribute-rewards.ja.md delete mode 100644 docs/contribute-rewards.ko.md delete mode 100644 docs/contribute-rewards.md delete mode 100644 docs/contribute-rewards.pt.md delete mode 100644 docs/contribute-rewards.zh.md diff --git a/docs/contribute-overview.md b/docs/contribute-overview.md index 608e073..4c5b5e7 100644 --- a/docs/contribute-overview.md +++ b/docs/contribute-overview.md @@ -26,15 +26,31 @@ Use this checklist to track your progress. **All items must be complete before y - [ ] Public IPv4 block allocated for DZ protocol (**see [DZ Prefix Rules](#dz-prefix-rules)**) ### Phase 2: Account Setup + +This phase alternates between the contributor and DZF. Each **DZF** item has to be confirmed before the next group can start. + +**Contributor** + +- [ ] GitHub username sent to DZF + +**DZF** + +- [ ] Access granted to the [malbeclabs/contributors](https://github.com/malbeclabs/contributors) repository + +**Contributor** + - [ ] Service keypair generated (`doublezero keygen`) - [ ] Metrics publisher keypair generated -- [ ] Rewards manager wallet created and funded with ~0.01 SOL -- [ ] Service key, rewards manager key and GitHub username submitted to DZF (public keys only) -- [ ] Contributor account created onchain (verify with `doublezero contributor list`) -- [ ] Rewards manager key registered onchain by DZF -- [ ] Access granted to [malbeclabs/contributors](https://github.com/malbeclabs/contributors) repository -- [ ] Recipient wallets and percentages configured (**see [Rewards Management](contribute-rewards.md)**) -- [ ] Each recipient wallet has a 2Z token account +- [ ] Service key **public key** sent to DZF + +**DZF** + +- [ ] Contributor account created onchain + +**Contributor** + +- [ ] Contributor account verified (`doublezero contributor list`) +- [ ] Rewards management set up (does not block going live, **see [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management) in the contributors repository**) ### Phase 3: Device Provisioning - [ ] Base device configuration applied (from contributors repo) @@ -55,7 +71,7 @@ Use this checklist to track your progress. **All items must be complete before y ### Phase 5: Link Burn-in - [ ] All links drained for 24-hour burn-in period -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) shows zero loss and zero errors for 24h +- [ ] [Link status dashboard](https://data.doublezero.xyz/status/links) shows zero loss and zero errors for 24h - [ ] Links undrained after clean burn-in ### Phase 6: Verification & Activation @@ -131,7 +147,7 @@ New to DoubleZero? Here are the essential terms (see [full Glossary](glossary.md | **Telemetry Agent** | Collects TWAMP latency/loss metrics, submits to onchain ledger | | **Service Key** | Your contributor identity key for CLI operations | | **Metrics Publisher Key** | Key for signing telemetry submissions onchain | -| **Rewards Manager Key** | Key that controls which wallets receive your rewards | +| **Rewards Manager Key** | Key that controls which wallets receive your rewards (see the contributors repository) | --- @@ -142,8 +158,7 @@ New to DoubleZero? Here are the essential terms (see [full Glossary](glossary.md | Guide | Description | |-------|-------------| | [Requirements & Architecture](contribute.md) | Hardware specs, network architecture, bandwidth options | -| [Device Provisioning](contribute-provisioning.md) | Step-by-step: keys → repo access → device → links → agents | -| [Rewards Management](contribute-rewards.md) | Setting the wallets that receive your 2Z rewards | +| [Device Provisioning](contribute-provisioning.md) | Step-by-step: repo access → keys → device → links → agents | | [Operations](contribute-operations.md) | Agent upgrades, link management, monitoring | | [Geoprobe Deployment](contribute-geolocation.md) | Deploying and configuring geoProbe agents for geolocation | | [Glossary](glossary.md) | All DoubleZero terminology defined | diff --git a/docs/contribute-provisioning.md b/docs/contribute-provisioning.md index 1092058..ba0569f 100644 --- a/docs/contribute-provisioning.md +++ b/docs/contribute-provisioning.md @@ -88,7 +88,7 @@ Before you can provision a device, you need the physical hardware set up and som | Requirement | Why It's Needed | |-------------|-----------------| | **DZD Hardware** | Arista 7280CR3A switch (see [hardware specs](contribute.md#hardware-requirements)) | -| **Rack Space** | 1U per DZD, with proper airflow. See [Rack & Power](contribute.md#rack-power-requirements) | +| **Rack Space** | 2U reserved per DZD (1U in use today), with proper airflow. See [Rack & Power](contribute.md#rack-power-requirements) | | **Power** | Two independent feeds, each able to carry the whole load on its own. See [Rack & Power](contribute.md#rack-power-requirements) | | **Management Access** | SSH/console access to configure the switch | | **Internet Connectivity** | For metrics publishing and to fetch configuration from the controller | @@ -163,9 +163,9 @@ flowchart LR ## Phase 2: Account Setup -In this phase, you create the cryptographic keys that identify you and your devices on the network, and you say where your rewards should be paid. +In this phase, you create the cryptographic keys that identify you and your devices on the network, and you set up rewards management. -Three keys come out of this phase: a service key, a metrics publisher key, and a rewards manager key. Submit the public keys for all three to DZF together in [Step 2.4](#step-24-submit-keys-to-dzf). [Rewards Management](contribute-rewards.md) covers the rewards side in full. +The steps run in this order for a reason: repository access first, because the repository holds the instructions for the later steps, then your keys, then rewards. Some steps need DZF to act before you can continue, and each one below says so. ### Where to Run the CLI @@ -201,7 +201,7 @@ Think of keys like secure login credentials: - **Service Key**: Your contributor identity - used to run CLI commands - **Metrics Publisher Key**: Your device's identity for submitting telemetry data -- **Rewards Manager Key**: Controls which wallets receive your rewards - see [Rewards Management](contribute-rewards.md) +- **Rewards Manager Key**: Controls which wallets receive your rewards - see [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management) in the contributors repository All three are cryptographic keypairs (a public key you share, a private key you keep secret). @@ -221,7 +221,13 @@ flowchart LR !!! note "Keep the rewards manager key separate" The service key and metrics publisher key live on your management server and switch. The rewards manager key controls where your money goes, so keep it off those machines. It is only needed when you change your recipient wallets. -### Step 2.1: Generate Your Service Key +### Step 2.1: Request Contributors Repository Access + +Contact the DoubleZero Foundation or Malbec Labs and give them your **GitHub username**. + +They grant you access to the private [malbeclabs/contributors](https://github.com/malbeclabs/contributors) repository. Do this first: the repository holds the base device configuration, the TCAM and ACL profiles, and the rewards management instructions you need in the steps below. + +### Step 2.2: Generate Your Service Key This is your main identity for interacting with DoubleZero. @@ -231,7 +237,7 @@ doublezero keygen This creates a keypair at the default location. The output shows your **public key** - this is what you'll share with DZF. -### Step 2.2: Generate Your Metrics Publisher Key +### Step 2.3: Generate Your Metrics Publisher Key This key is used by the Telemetry Agent to sign metric submissions. @@ -239,32 +245,14 @@ This key is used by the Telemetry Agent to sign metric submissions. doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Step 2.3: Create Your Rewards Manager Wallet - -This is the third key. It controls which wallets receive your rewards, and it never holds them. - -Create a Solana wallet you control and can sign with, then fund it with about 0.01 SOL to cover transaction fees. A hardware wallet is a good choice. Do not reuse your service key. - -You only need the wallet at this point. You will set the wallets that actually receive your rewards in [Step 2.7](#step-27-set-your-reward-recipients), after DZF has registered this key. - -### Step 2.4: Submit Keys to DZF +### Step 2.4: Submit Your Service Key to DZF -Contact the DoubleZero Foundation or Malbec Labs and provide: +Send DZF your **service key public key**. -1. Your **service key public key** -2. Your **rewards manager public key** (from Step 2.3) -3. Your **GitHub username** (for repo access) - -Send all three together. DZF registers the service key and the rewards manager key in separate onchain transactions, so sending them at the same time saves a round trip. +They create your **contributor account** onchain and confirm when it is done. !!! danger "Public keys only" - Never send a private key or a keypair file to anyone, including DZF. DZF only ever needs your public keys. - -They will: - -- Create your **contributor account** onchain -- Register your **rewards manager key** against your service key -- Grant access to the private **contributors repository** + Never send a private key or a keypair file to anyone, including DZF. Only the public key is ever needed. ### Step 2.5: Verify Your Account @@ -276,36 +264,14 @@ doublezero contributor list You should see your contributor code in the list. -Check that your rewards manager key was registered too: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` - -The `manager` column should show your rewards manager public key. If it is empty, ask DZF to complete that step. +### Step 2.6: Set Up Rewards Management -### Step 2.6: Access the Contributors Repository +Rewards management decides which wallets receive the [2Z](glossary.md#2z-token) your contribution earns, and in what proportions. -The [malbeclabs/contributors](https://github.com/malbeclabs/contributors) repository contains: +Follow [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management) in the contributors repository, which you now have access to from Step 2.1. -- Base device configurations -- TCAM profiles -- ACL configurations -- Additional setup instructions - -Follow the instructions there for device-specific configuration. - -### Step 2.7: Set Your Reward Recipients - -Now say which wallets receive your rewards, and in what proportions. Do this before your device starts carrying traffic. Rewards build up from the moment your links are live, but the protocol cannot pay them out until you have nominated recipient wallets. - -Sign in to [doublezero.xyz/rewards](https://doublezero.xyz/rewards) with your rewards manager wallet, select your service key, then enter each recipient wallet and its percentage. The percentages must add up to 100. - -!!! warning "Each recipient needs a 2Z token account" - The protocol sends 2Z with a plain token transfer and does not create the token account for you. A recipient wallet with no 2Z token account causes that epoch's payout to fail. - -See [Rewards Management](contribute-rewards.md) for the full walkthrough, including the CLI alternative, how to check the token account, and how to verify the result. +!!! note "This does not block the rest of your setup" + You can provision your device, establish links and start carrying traffic without this in place, so treat the phases below as independent of it. --- @@ -990,10 +956,26 @@ You should see "Starting telemetry collector" and "Starting submission loop". !!! warning "All new links must burn in before carrying traffic" New links must be **drained for at least 24 hours** before being activated for production traffic. This burn-in requirement is defined in [RFC12: Network Provisioning](https://github.com/malbeclabs/doublezero/blob/main/rfcs/rfc12-network-provisioning.md), which specifies ~200,000 DZ Ledger slots (~20 hours) of clean metrics before a link is ready for service. -With agents installed and running, monitor your links on [metrics.doublezero.xyz](https://metrics.doublezero.xyz) for at least 24 consecutive hours: +With agents installed and running, monitor each new link for at least 24 consecutive hours. + +Take the link's account key from the `account` column of `doublezero link list`, then open its page on the data portal: + +``` +https://data.doublezero.xyz/dz/links/ +``` + +The page opens on a 24 hour window, which is the burn-in period. Check that all of these stay clean for the whole window: + +| Chart | What to look for | +|-------|------------------| +| **Health** | No red bars. Hover a bar to see why it was flagged | +| **Packet loss** | Flat at zero. Taken from the TWAMP measurements between the two devices | +| **Interface issues** | Nothing plotted at all. Errors, FCS errors, discards and carrier transitions all appear here, with side A above the axis and side Z below it | +| **Latency**, **Jitter** | Steady, with no steps or spikes | + +Carrier transitions deserve particular attention: they mean the link went down and came back up, so it is not stable yet even if the other charts look clean. -- **"DoubleZero Device-Link Latencies"** dashboard — verify **zero packet loss** on the link over time -- **"DoubleZero Network Metrics"** dashboard — verify **zero errors** on your links +To check several links at once, use the [link status dashboard](https://data.doublezero.xyz/status/links). Only undrain the link once the burn-in period shows a clean link with zero loss and zero errors. @@ -1008,7 +990,7 @@ Run through this checklist to confirm everything is working. **Before setting `max_users` above 0, you must:** - 1. Confirm all links have completed their **24-hour burn-in** with zero loss/errors on [metrics.doublezero.xyz](https://metrics.doublezero.xyz) + 1. Confirm all links have completed their **24-hour burn-in** with zero loss/errors on the [link status dashboard](https://data.doublezero.xyz/status/links) 2. **Coordinate with DZ/Malbec Labs** to run a connectivity test: - Can a test user connect to your device? - Does the user receive routes over the DZ network? diff --git a/docs/contribute-rewards.es.md b/docs/contribute-rewards.es.md deleted file mode 100644 index f290cf9..0000000 --- a/docs/contribute-rewards.es.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: Configura la gestión de recompensas para que las recompensas en 2Z obtenidas por tu contribución a DoubleZero se paguen a las billeteras que tú controlas. ---- - -# Gestión de Recompensas - -Ganas recompensas en [2Z](glossary.md#2z-token) por el ancho de banda y los dispositivos que contribuyes. El protocolo paga esas recompensas por sí mismo, directamente a las billeteras que tú designes. Hasta que las designes, no se puede realizar ningún pago. - -!!! warning "Haz esto durante la configuración de la cuenta" - Configura la gestión de recompensas en la [Fase 2: Configuración de la Cuenta](contribute-provisioning.md#phase-2-account-setup), antes de que tu dispositivo transporte tráfico. - - Tus recompensas siguen acumulándose si dejas esto para después. El protocolo no las quema y no expiran. Lo que pierdes es el pago automático: el proceso de pago rutinario trabaja con las épocas recientes, por lo que cualquier época que pase mientras no tengas destinatarios configurados tiene que pagarse manualmente después. Consulta [Si Configuras Esto Tarde](#si-configuras-esto-tarde). - ---- - -## Cómo Funciona - -Están involucradas tres claves. Cada una hace un trabajo diferente, y es más seguro mantenerlas separadas. - -| Clave | Qué hace | ¿Recibe recompensas? | -|-------|----------|----------------------| -| **Clave de servicio** | Te identifica como contribuidor y firma tus comandos CLI. También nombra tu cuenta de recompensas onchain. | No | -| **Clave del gestor de recompensas** | Firma los cambios en la lista de billeteras que reciben recompensas. | No | -| **Billetera(s) destinataria(s)** | Almacena los 2Z que el protocolo te envía. Hasta 8 billeteras. | Sí | - -La DoubleZero Foundation registra tu clave del gestor de recompensas contra tu clave de servicio. Solo DZF puede hacer eso. Después de eso, solo tu clave del gestor de recompensas puede cambiar la lista de destinatarios, y DZF no puede redirigir tus recompensas. - -```mermaid -flowchart LR - DZF["DZF"] -->|"Registra tu
clave del gestor de recompensas"| ACC["Tu cuenta de recompensas
onchain"] - RM["Clave del gestor de recompensas
(tú la conservas, mantenla offline)"] -->|"Establece destinatarios
y porcentajes"| ACC - ACC --> R1["Billetera destinataria 1"] - ACC --> R2["Billetera destinataria 2"] - PROTO["El protocolo paga
cada época DZ"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## Qué Necesitas Primero - -- Una cuenta de contribuidor onchain. Verifica con `doublezero contributor list`. -- Una billetera Solana para actuar como tu gestor de recompensas, con aproximadamente 0.01 SOL para pagar las comisiones de transacción. -- Una o más billeteras para recibir los 2Z. -- El CLI `doublezero-solana`, si quieres usar la línea de comandos en lugar del portal. Instálalo con `sudo apt update && sudo apt install doublezero-solana`. - -!!! tip "Usa una billetera de hardware para la clave del gestor de recompensas" - La clave del gestor de recompensas controla hacia dónde va tu dinero. Mantenla en una billetera de hardware o de otro modo offline. Nunca necesita estar en un servidor, y nunca almacena tus recompensas. - ---- - -## Paso 1: Crea Tu Billetera del Gestor de Recompensas - -Crea una billetera Solana que controles y con la que puedas firmar. Puede ser una billetera de hardware, una billetera de navegador o un archivo de par de claves. - -Fondéala con una pequeña cantidad de SOL, aproximadamente 0.01 SOL. Esto solo paga las comisiones de red cuando cambias tu lista de destinatarios. - -No reutilices tu clave de servicio para esto. Si la clave de servicio está en un servidor de gestión, cualquiera que acceda a ese servidor podría redirigir tus recompensas. - ---- - -## Paso 2: Envía la Clave Pública a DZF - -Entrega a DZF la **clave pública** de tu billetera del gestor de recompensas. Nunca compartas la clave privada. - -DZF la registra contra tu clave de servicio onchain y confirma cuando está hecho. No puedes hacer este paso tú mismo. - -!!! tip "Envíala junto con tu clave de servicio" - Si estás siguiendo la [Guía de Aprovisionamiento de Dispositivos](contribute-provisioning.md), envía esta clave pública al mismo tiempo que tu clave de servicio y nombre de usuario de GitHub, en el [Paso 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). DZF registra las dos claves en transacciones separadas, así que enviarlas juntas ahorra un ida y vuelta. - -Puedes verificar que se registró: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -La columna `manager` muestra tu clave del gestor de recompensas. Si está vacía, DZF aún no la ha registrado. - ---- - -## Paso 3: Configura Tus Billeteras Destinatarias - -Ahora indica a dónde deben ir las recompensas. Puedes usar el portal web o el CLI. Ambos escriben lo mismo onchain. - -Reglas que aplican en cualquier caso: - -- Como máximo 8 billeteras destinatarias. -- Los porcentajes deben ser números enteros y deben sumar exactamente 100. -- Un destinatario no puede tener una participación del 0%. Elimínalo en su lugar. - -!!! info "Si tu acuerdo con DZF incluye una distribución de ingresos" - Algunos contribuidores tienen un acuerdo que divide las recompensas con la fundación, por ejemplo cuando DZF proporcionó el hardware. Si eso aplica para ti, DZF te da la dirección y el porcentaje que debes ingresar aquí. Pregunta a DZF si no estás seguro. - -=== "Portal web" - - 1. Ve a [doublezero.xyz/rewards](https://doublezero.xyz/rewards). La dirección anterior, `rewards.doublezero.xyz`, redirige aquí. - 2. Conecta tu billetera del gestor de recompensas con el botón de billetera en la esquina superior derecha. - 3. Selecciona tu clave de servicio de la lista en la siguiente página. - 4. Ingresa cada dirección de billetera destinataria y su porcentaje. El total debe ser 100%. - 5. Haz clic en **Submit** y aprueba la transacción en tu billetera. - -=== "CLI" - - Ejecuta esto con tu par de claves del gestor de recompensas como `-k`. Repite `--recipient` para cada billetera. - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | Flag | Descripción | - |------|-------------| - | `--service-key` | Tu clave de servicio de contribuidor. Nombra la cuenta de recompensas onchain. | - | `--recipient` | Un destinatario en el formato `PUBKEY:PERCENT`. Números enteros, de 1 a 100, que sumen 100. Máximo 8. | - | `-k` | Tu par de claves del gestor de recompensas. La transacción falla si este no es el gestor de recompensas registrado. | - | `-u` | `mainnet-beta`. | - - Agrega `--dry-run` primero si quieres simular la transacción sin enviarla. - ---- - -## Paso 4: Verifica Que Cada Destinatario Pueda Recibir 2Z - -El protocolo envía 2Z con una transferencia de tokens simple. **No** crea la cuenta de tokens por ti. Si una billetera destinataria no tiene una cuenta de tokens 2Z, el pago de esa época falla. - -El mint de 2Z en mainnet es: - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -Lista las cuentas de tokens que una billetera ya tiene: - -```bash -spl-token accounts --owner -u m -``` - -Si `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` no aparece en esa lista, crea la cuenta una vez: - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -Cualquier billetera con fondos puede pagar esto. Cuesta una pequeña cantidad de SOL y solo necesita hacerse una vez por billetera destinataria. - -!!! note "Las billeteras que ya tienen 2Z están bien" - Si la billetera ha recibido 2Z alguna vez, la cuenta de tokens existe y puedes omitir este paso. - ---- - -## Paso 5: Verificar - -Comprueba lo que ahora está registrado onchain: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -Ejemplo de salida: - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -La columna `ata` es la cuenta de tokens 2Z en la que se pagará a cada destinatario. Verifica que la columna `proportion` sume 100%. - ---- - -## Cuándo Llegan las Recompensas - -- Las recompensas se calculan por **época DZ**, que es la época del DoubleZero Ledger. Una época DZ dura aproximadamente dos días. -- El pago de una época ocurre alrededor de 10 épocas DZ después de que esa época termina, es decir, aproximadamente 20 días después. Este retraso cubre la contabilidad de la época. -- Los pagos son automáticos. No necesitas reclamarlos y no necesitas ejecutar nada. -- Una vez que tus destinatarios están configurados, los pagos comienzan a llegar en un par de días a medida que se procesan las siguientes épocas. Las épocas que pasaron antes de que configuraras tus destinatarios son un asunto separado, consulta [Si Configuras Esto Tarde](#si-configuras-esto-tarde). -- Una época DZ y una época de Solana no tienen la misma duración. Esa diferencia se acumula con el tiempo, por lo que de vez en cuando una época DZ muestra cero recompensas. Esto es esperado. - ---- - -## Dónde Ver Tus Recompensas - -**Vista agregada.** El [Economic Hub](https://doublezero.xyz/economic-hub) muestra las recompensas de los contribuidores a nivel de red. - -**Por época.** Consulta al protocolo lo que pagó una época DZ determinada: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -La salida lista cada contribuidor con su participación, su recompensa en 2Z, y si el pago ha sido realizado. Busca tu código de contribuidor en la columna `contributor`. - -Para ver en qué época DZ está la red ahora, omite `-e`: - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "Las épocas recientes aún no son definitivas" - Consultar una época cuyas recompensas aún no se han calculado devuelve `Rewards calculation is not finalized yet`. Prueba con una época más antigua. - ---- - -## Si Configuras Esto Tarde - -Las recompensas se calculan para cada época en la que contribuiste, tengas o no destinatarios configurados en ese momento. Esas recompensas no se queman y no expiran. Permanecen en la cuenta de distribución de esa época hasta que alguien envíe el pago. - -El inconveniente es que nada las envía por ti después del hecho. El proceso de pago rutinario trabaja con las épocas recientes, por lo que una época que pasó mientras tu lista de destinatarios estaba vacía permanece sin pagar hasta que se envíe manualmente. - -Para encontrar qué épocas están afectadas, busca filas con tu código de contribuidor donde `distributed` sea `no` y la recompensa sea mayor que cero: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -Enviar el pago es sin permisos (permissionless), así que una vez que tus destinatarios estén configurados, cualquier billetera con fondos puede hacerlo, incluyendo la tuya: - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -Agrega `--dry-run` primero para simularlo sin enviar nada. El comando procesa cada contribuidor en esa época y omite los que ya fueron pagados, así que es seguro ejecutarlo. - -Si prefieres no hacer esto tú mismo, pide a DZF que envíe las épocas por ti. - ---- - -## Cambiar Destinatarios Después - -Repite el [Paso 3](#paso-3-configura-tus-billeteras-destinatarias) en cualquier momento. La nueva lista reemplaza la anterior por completo, así que incluye todos los destinatarios que aún deseas, no solo los que estás agregando. Los porcentajes deben sumar 100 nuevamente. - -Recuerda el [Paso 4](#paso-4-verifica-que-cada-destinatario-pueda-recibir-2z) para cualquier billetera que agregues. - ---- - -## Bloquear la Clave del Gestor de Recompensas - -Por defecto, DZF puede cambiar tu clave del gestor de recompensas, lo cual es útil si pierdes acceso a ella. Si prefieres descartar esa posibilidad, puedes bloquearla: - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "No bloquees una clave que podrías perder" - Una vez que la gestión está bloqueada, nadie puede reemplazar tu clave del gestor de recompensas, incluyendo DZF. Si luego pierdes esa clave, ya no podrás cambiar a dónde van tus recompensas. Solo bloquéala si la clave está respaldada y segura. - -Para permitirlo nuevamente, ejecuta el mismo comando con `--allow-protocol-management`. - ---- - -## Solución de Problemas - -**La columna `manager` está vacía.** -DZF aún no ha registrado tu clave del gestor de recompensas. Envíales la clave pública y pídeles que confirmen. - -**`Invalid rewards manager`.** -El par de claves con el que firmaste no es el gestor de recompensas registrado. Verifica que pasaste el archivo correcto a `-k`, o la billetera correcta en el portal. - -**`Invalid recipients`.** -Tus porcentajes no suman exactamente 100, listaste más de 8 destinatarios, o uno de ellos tiene una participación del 0%. - -**Las recompensas aparecen como ganadas pero nada llega.** -Dos causas comunes. O no hay destinatarios configurados, por lo que no hay a dónde enviarlas, o una billetera destinataria no tiene cuenta de tokens 2Z. Revisa el [Paso 4](#paso-4-verifica-que-cada-destinatario-pueda-recibir-2z) y el [Paso 5](#paso-5-verificar). Una vez corregido, las épocas futuras se pagan solas. Las épocas que ya pasaron necesitan [un pago manual](#si-configuras-esto-tarde). - -**Tus recompensas para una época reciente son 0.** -Las recompensas tienen un retraso de aproximadamente 10 épocas DZ. Consulta una época que tenga al menos esa antigüedad. Las épocas con cero ocasionales también son normales, consulta [Cuándo Llegan las Recompensas](#cuándo-llegan-las-recompensas). - ---- - -## Próximos Pasos - -Vuelve a la [Lista de Verificación de Incorporación](contribute-overview.md#onboarding-checklist), o continúa con [Operaciones](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.fr.md b/docs/contribute-rewards.fr.md deleted file mode 100644 index 8809331..0000000 --- a/docs/contribute-rewards.fr.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: Configurez la gestion des récompenses afin que les récompenses en 2Z générées par votre contribution à DoubleZero soient versées aux portefeuilles que vous contrôlez. ---- - -# Gestion des récompenses - -Vous gagnez des récompenses en [2Z](glossary.md#2z-token) pour la bande passante et les appareils que vous contribuez. Le protocole verse ces récompenses de lui-même, directement aux portefeuilles que vous désignez. Tant que vous ne les avez pas désignés, aucun versement ne peut être effectué. - -!!! warning "Faites ceci lors de la configuration du compte" - Configurez la gestion des récompenses lors de la [Phase 2 : Configuration du compte](contribute-provisioning.md#phase-2-account-setup), avant que votre appareil ne transporte du trafic. - - Vos récompenses continuent de s'accumuler si vous reportez cette étape. Le protocole ne les détruit pas et elles n'expirent pas. Ce que vous perdez, c'est le versement automatique : le processus de versement de routine traite les époques récentes, donc toute époque passée alors que vous n'avez pas de destinataires configurés devra être versée manuellement par la suite. Voir [Si vous configurez ceci tardivement](#si-vous-configurez-ceci-tardivement). - ---- - -## Comment ça fonctionne - -Trois clés sont impliquées. Chacune remplit un rôle différent, et il est plus sûr de les garder séparées. - -| Clé | Ce qu'elle fait | Reçoit des récompenses ? | -|-----|-----------------|--------------------------| -| **Clé de service** | Vous identifie en tant que contributeur et signe vos commandes CLI. Désigne également votre compte de récompenses onchain. | Non | -| **Clé du gestionnaire de récompenses** | Signe les modifications de la liste des portefeuilles recevant les récompenses. | Non | -| **Portefeuille(s) destinataire(s)** | Détient les 2Z que le protocole vous envoie. Jusqu'à 8 portefeuilles. | Oui | - -La DoubleZero Foundation enregistre votre clé de gestionnaire de récompenses en lien avec votre clé de service. Seule la DZF peut le faire. Ensuite, seule votre clé de gestionnaire de récompenses peut modifier la liste des destinataires, et la DZF ne peut pas rediriger vos récompenses. - -```mermaid -flowchart LR - DZF["DZF"] -->|"Enregistre votre
clé de gestionnaire de récompenses"| ACC["Votre compte de récompenses
onchain"] - RM["Clé du gestionnaire de récompenses
(vous la détenez, gardez-la hors ligne)"] -->|"Définit les destinataires
et les pourcentages"| ACC - ACC --> R1["Portefeuille destinataire 1"] - ACC --> R2["Portefeuille destinataire 2"] - PROTO["Le protocole verse
à chaque époque DZ"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## Ce dont vous avez besoin au préalable - -- Un compte contributeur onchain. Vérifiez avec `doublezero contributor list`. -- Un portefeuille Solana pour servir de gestionnaire de récompenses, détenant environ 0,01 SOL pour payer les frais de transaction. -- Un ou plusieurs portefeuilles pour recevoir les 2Z. -- Le CLI `doublezero-solana`, si vous souhaitez utiliser la ligne de commande plutôt que le portail. Installez-le avec `sudo apt update && sudo apt install doublezero-solana`. - -!!! tip "Utilisez un portefeuille matériel pour la clé du gestionnaire de récompenses" - La clé du gestionnaire de récompenses contrôle où va votre argent. Conservez-la sur un portefeuille matériel ou hors ligne. Elle n'a jamais besoin de se trouver sur un serveur, et elle ne détient jamais vos récompenses. - ---- - -## Étape 1 : Créez votre portefeuille de gestionnaire de récompenses - -Créez un portefeuille Solana que vous contrôlez et avec lequel vous pouvez signer. Il peut s'agir d'un portefeuille matériel, d'un portefeuille de navigateur ou d'un fichier de paire de clés. - -Approvisionnez-le avec une petite quantité de SOL, environ 0,01 SOL. Cela sert uniquement à payer les frais réseau lorsque vous modifiez votre liste de destinataires. - -Ne réutilisez pas votre clé de service pour cela. Si la clé de service se trouve sur un serveur de gestion, toute personne ayant accès à ce serveur pourrait rediriger vos récompenses. - ---- - -## Étape 2 : Envoyez la clé publique à la DZF - -Transmettez à la DZF la **clé publique** de votre portefeuille de gestionnaire de récompenses. Ne partagez jamais la clé privée. - -La DZF l'enregistre en lien avec votre clé de service onchain et confirme lorsque c'est fait. Vous ne pouvez pas effectuer cette étape vous-même. - -!!! tip "Envoyez-la en même temps que votre clé de service" - Si vous suivez le [Guide de provisionnement des appareils](contribute-provisioning.md), envoyez cette clé publique en même temps que votre clé de service et votre nom d'utilisateur GitHub, à l'[Étape 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). La DZF enregistre les deux clés dans des transactions séparées, donc les envoyer ensemble permet d'économiser un aller-retour. - -Vous pouvez vérifier qu'elle a bien été enregistrée : - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -La colonne `manager` affiche votre clé de gestionnaire de récompenses. Si elle est vide, la DZF ne l'a pas encore enregistrée. - ---- - -## Étape 3 : Définissez vos portefeuilles destinataires - -Indiquez maintenant où les récompenses doivent être envoyées. Vous pouvez utiliser le portail web ou le CLI. Les deux écrivent la même chose onchain. - -Règles applicables dans les deux cas : - -- Au maximum 8 portefeuilles destinataires. -- Les pourcentages doivent être des nombres entiers et doivent totaliser exactement 100. -- Un destinataire ne peut pas avoir une part de 0 %. Supprimez-le à la place. - -!!! info "Si votre accord avec la DZF inclut un partage de revenus" - Certains contributeurs ont un accord qui partage les récompenses avec la fondation, par exemple lorsque la DZF a fourni le matériel. Si c'est votre cas, la DZF vous fournit l'adresse et le pourcentage à saisir ici. Demandez à la DZF si vous n'êtes pas sûr. - -=== "Portail web" - - 1. Rendez-vous sur [doublezero.xyz/rewards](https://doublezero.xyz/rewards). L'ancienne adresse, `rewards.doublezero.xyz`, redirige ici. - 2. Connectez votre portefeuille de gestionnaire de récompenses avec le bouton de portefeuille en haut à droite. - 3. Sélectionnez votre clé de service dans la liste sur la page suivante. - 4. Saisissez chaque adresse de portefeuille destinataire et son pourcentage. Le total doit être de 100 %. - 5. Cliquez sur **Submit** et approuvez la transaction dans votre portefeuille. - -=== "CLI" - - Exécutez ceci avec votre paire de clés du gestionnaire de récompenses en tant que `-k`. Répétez `--recipient` pour chaque portefeuille. - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | Drapeau | Description | - |---------|-------------| - | `--service-key` | Votre clé de service contributeur. Elle désigne le compte de récompenses onchain. | - | `--recipient` | Un destinataire sous la forme `PUBKEY:PERCENT`. Nombres entiers, de 1 à 100, totalisant 100. Maximum 8. | - | `-k` | Votre paire de clés du gestionnaire de récompenses. La transaction échoue si ce n'est pas le gestionnaire de récompenses enregistré. | - | `-u` | `mainnet-beta`. | - - Ajoutez d'abord `--dry-run` si vous souhaitez simuler la transaction sans l'envoyer. - ---- - -## Étape 4 : Vérifiez que chaque destinataire peut détenir des 2Z - -Le protocole envoie des 2Z par un simple transfert de jetons. Il ne crée **pas** le compte de jetons pour vous. Si un portefeuille destinataire n'a pas de compte de jetons 2Z, le versement pour cette époque échoue. - -L'adresse de mint du 2Z sur mainnet est : - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -Listez les comptes de jetons qu'un portefeuille possède déjà : - -```bash -spl-token accounts --owner -u m -``` - -Si `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` est absent de cette liste, créez le compte une seule fois : - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -N'importe quel portefeuille approvisionné peut payer cela. Cela coûte une petite quantité de SOL et ne doit être fait qu'une seule fois par portefeuille destinataire. - -!!! note "Les portefeuilles qui détiennent déjà des 2Z sont OK" - Si le portefeuille a déjà reçu des 2Z, le compte de jetons existe et vous pouvez ignorer cette étape. - ---- - -## Étape 5 : Vérification - -Vérifiez ce qui est désormais enregistré onchain : - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -Exemple de sortie : - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -La colonne `ata` est le compte de jetons 2Z dans lequel chaque destinataire sera payé. Vérifiez que la colonne `proportion` totalise 100 %. - ---- - -## Quand les récompenses arrivent - -- Les récompenses sont calculées par **époque DZ**, qui est l'époque du DoubleZero Ledger. Une époque DZ dure environ deux jours. -- Le versement pour une époque a lieu environ 10 époques DZ après la fin de cette époque, soit environ 20 jours plus tard. Ce délai couvre la comptabilisation de l'époque. -- Les versements sont automatiques. Vous n'avez pas à les réclamer, et vous n'avez rien à exécuter. -- Une fois vos destinataires définis, les versements commencent à arriver sous quelques jours à mesure que les prochaines époques sont traitées. Les époques passées avant que vous ne définissiez vos destinataires sont un cas à part, voir [Si vous configurez ceci tardivement](#si-vous-configurez-ceci-tardivement). -- Une époque DZ et une époque Solana n'ont pas la même durée. Cette différence s'accumule au fil du temps, si bien que de temps en temps une époque DZ affiche zéro récompense. C'est normal. - ---- - -## Où consulter vos récompenses - -**Vue agrégée.** Le [Economic Hub](https://doublezero.xyz/economic-hub) affiche les récompenses des contributeurs au niveau du réseau. - -**Par époque.** Interrogez le protocole sur ce qu'une époque DZ donnée a versé : - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -La sortie liste chaque contributeur avec sa part, sa récompense en 2Z, et si le versement a été effectué. Retrouvez votre code contributeur dans la colonne `contributor`. - -Pour voir à quelle époque DZ le réseau en est actuellement, omettez `-e` : - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "Les époques récentes ne sont pas encore finalisées" - Interroger une époque dont les récompenses n'ont pas encore été calculées renvoie `Rewards calculation is not finalized yet`. Essayez une époque plus ancienne. - ---- - -## Si vous configurez ceci tardivement - -Les récompenses sont calculées pour chaque époque à laquelle vous avez contribué, que vous ayez eu ou non des destinataires configurés à ce moment-là. Ces récompenses ne sont pas détruites et n'expirent pas. Elles restent dans le compte de distribution de cette époque jusqu'à ce que quelqu'un soumette le versement. - -Le problème est que rien ne les soumet pour vous après coup. Le processus de versement de routine traite les époques récentes, donc une époque passée alors que votre liste de destinataires était vide reste impayée jusqu'à ce qu'elle soit soumise manuellement. - -Pour trouver quelles époques sont concernées, cherchez les lignes avec votre code contributeur où `distributed` est `no` et la récompense est supérieure à zéro : - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -Soumettre le versement est sans permission, donc une fois vos destinataires configurés, n'importe quel portefeuille approvisionné peut le faire, y compris le vôtre : - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -Ajoutez d'abord `--dry-run` pour simuler sans rien envoyer. La commande traite chaque contributeur de cette époque et ignore ceux déjà payés, donc elle est sûre à exécuter. - -Si vous préférez ne pas le faire vous-même, demandez à la DZF de soumettre les époques pour vous. - ---- - -## Modifier les destinataires ultérieurement - -Répétez l'[Étape 3](#etape-3-definissez-vos-portefeuilles-destinataires) à tout moment. La nouvelle liste remplace entièrement l'ancienne, donc incluez chaque destinataire que vous souhaitez toujours, pas seulement ceux que vous ajoutez. Les pourcentages doivent à nouveau totaliser 100. - -N'oubliez pas l'[Étape 4](#etape-4-verifiez-que-chaque-destinataire-peut-detenir-des-2z) pour tout portefeuille que vous ajoutez. - ---- - -## Verrouiller la clé du gestionnaire de récompenses - -Par défaut, la DZF peut modifier votre clé de gestionnaire de récompenses, ce qui est utile si vous en perdez l'accès. Si vous préférez exclure cette possibilité, vous pouvez la bloquer : - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "Ne verrouillez pas une clé que vous pourriez perdre" - Une fois la gestion bloquée, personne ne peut remplacer votre clé de gestionnaire de récompenses, y compris la DZF. Si vous perdez ensuite cette clé, vous ne pourrez plus modifier la destination de vos récompenses. Ne bloquez que si la clé est sauvegardée et en sécurité. - -Pour autoriser à nouveau la gestion, exécutez la même commande avec `--allow-protocol-management`. - ---- - -## Dépannage - -**La colonne `manager` est vide.** -La DZF n'a pas encore enregistré votre clé de gestionnaire de récompenses. Envoyez-leur la clé publique et demandez-leur de confirmer. - -**`Invalid rewards manager`.** -La paire de clés avec laquelle vous avez signé n'est pas le gestionnaire de récompenses enregistré. Vérifiez que vous avez passé le bon fichier à `-k`, ou le bon portefeuille dans le portail. - -**`Invalid recipients`.** -Vos pourcentages ne totalisent pas exactement 100, vous avez listé plus de 8 destinataires, ou l'un d'eux a une part de 0 %. - -**Les récompenses apparaissent comme gagnées mais rien n'arrive.** -Deux causes fréquentes. Soit aucun destinataire n'est configuré, donc il n'y a nulle part où les envoyer, soit un portefeuille destinataire n'a pas de compte de jetons 2Z. Suivez l'[Étape 4](#etape-4-verifiez-que-chaque-destinataire-peut-detenir-des-2z) et l'[Étape 5](#etape-5-verification). Une fois cela corrigé, les époques futures seront versées automatiquement. Les époques déjà passées nécessitent [un versement manuel](#si-vous-configurez-ceci-tardivement). - -**Vos récompenses pour une époque récente sont de 0.** -Les récompenses ont un décalage d'environ 10 époques DZ. Vérifiez une époque qui a au moins cet âge. Des époques occasionnelles à zéro sont également normales, voir [Quand les récompenses arrivent](#quand-les-recompenses-arrivent). - ---- - -## Prochaines étapes - -Retour à la [Liste de contrôle d'intégration](contribute-overview.md#onboarding-checklist), ou passez à [Opérations](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.it.md b/docs/contribute-rewards.it.md deleted file mode 100644 index f48ad03..0000000 --- a/docs/contribute-rewards.it.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: Configura la gestione delle ricompense affinché le ricompense in 2Z guadagnate con il tuo contributo a DoubleZero vengano pagate ai wallet che controlli. ---- - -# Gestione delle Ricompense - -Guadagni ricompense in [2Z](glossary.md#2z-token) per la larghezza di banda e i dispositivi che contribuisci. Il protocollo paga queste ricompense autonomamente, direttamente ai wallet che designi. Finché non li designi, nessun pagamento può essere effettuato. - -!!! warning "Fai questo durante la configurazione dell'account" - Configura la gestione delle ricompense nella [Fase 2: Configurazione dell'Account](contribute-provisioning.md#phase-2-account-setup), prima che il tuo dispositivo trasporti traffico. - - Le tue ricompense continuano a maturare anche se rimandi questa operazione. Il protocollo non le brucia e non scadono. Ciò che perdi è il pagamento automatico: il processo di pagamento di routine elabora le epoche recenti, quindi qualsiasi epoca trascorsa mentre non hai destinatari configurati dovrà essere pagata manualmente in seguito. Vedi [Se Configuri Questo in Ritardo](#se-configuri-questo-in-ritardo). - ---- - -## Come Funziona - -Sono coinvolte tre chiavi. Ognuna svolge un compito diverso, ed è più sicuro tenerle separate. - -| Chiave | Cosa fa | Riceve ricompense? | -|--------|---------|-------------------| -| **Chiave di servizio** | Ti identifica come contributore e firma i tuoi comandi CLI. Inoltre nomina il tuo account ricompense onchain. | No | -| **Chiave del gestore ricompense** | Firma le modifiche alla lista dei wallet che ricevono le ricompense. | No | -| **Wallet destinatari** | Contiene i 2Z che il protocollo ti invia. Fino a 8 wallet. | Sì | - -La DoubleZero Foundation registra la tua chiave del gestore ricompense associandola alla tua chiave di servizio. Solo DZF può farlo. Dopodiché, solo la tua chiave del gestore ricompense può modificare la lista dei destinatari, e DZF non può reindirizzare le tue ricompense. - -```mermaid -flowchart LR - DZF["DZF"] -->|"Registra la tua
chiave del gestore ricompense"| ACC["Il tuo account ricompense
onchain"] - RM["Chiave del gestore ricompense
(la tieni tu, conservala offline)"] -->|"Imposta destinatari
e percentuali"| ACC - ACC --> R1["Wallet destinatario 1"] - ACC --> R2["Wallet destinatario 2"] - PROTO["Il protocollo paga
ogni epoca DZ"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## Cosa Ti Serve Prima - -- Un account contributore onchain. Verifica con `doublezero contributor list`. -- Un wallet Solana da usare come gestore ricompense, con circa 0,01 SOL per pagare le commissioni di transazione. -- Uno o più wallet per ricevere i 2Z. -- La CLI `doublezero-solana`, se vuoi usare la riga di comando invece del portale. Installala con `sudo apt update && sudo apt install doublezero-solana`. - -!!! tip "Usa un hardware wallet per la chiave del gestore ricompense" - La chiave del gestore ricompense controlla dove vanno i tuoi fondi. Conservala su un hardware wallet o comunque offline. Non ha mai bisogno di risiedere su un server e non detiene mai le tue ricompense. - ---- - -## Passo 1: Crea il Tuo Wallet del Gestore Ricompense - -Crea un wallet Solana che controlli e con cui puoi firmare. Può essere un hardware wallet, un wallet del browser o un file keypair. - -Caricalo con una piccola quantità di SOL, circa 0,01 SOL. Questo serve solo a pagare le commissioni di rete quando modifichi la lista dei destinatari. - -Non riutilizzare la tua chiave di servizio per questo. Se la chiave di servizio risiede su un server di gestione, chiunque raggiunga quel server potrebbe reindirizzare le tue ricompense. - ---- - -## Passo 2: Invia la Chiave Pubblica a DZF - -Fornisci a DZF la **chiave pubblica** del tuo wallet del gestore ricompense. Non condividere mai la chiave privata. - -DZF la registra associandola alla tua chiave di servizio onchain e conferma quando è completato. Non puoi eseguire questo passaggio autonomamente. - -!!! tip "Inviala insieme alla tua chiave di servizio" - Se stai seguendo la [Guida al Provisioning del Dispositivo](contribute-provisioning.md), invia questa chiave pubblica contemporaneamente alla tua chiave di servizio e al nome utente GitHub, nel [Passo 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). DZF registra le due chiavi in transazioni separate, quindi inviarle insieme fa risparmiare un passaggio. - -Puoi verificare che sia stata registrata: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -La colonna `manager` mostra la tua chiave del gestore ricompense. Se è vuota, DZF non l'ha ancora registrata. - ---- - -## Passo 3: Imposta i Tuoi Wallet Destinatari - -Ora indica dove devono andare le ricompense. Puoi usare il portale web o la CLI. Entrambi scrivono la stessa cosa onchain. - -Regole valide in entrambi i casi: - -- Al massimo 8 wallet destinatari. -- Le percentuali devono essere numeri interi e devono sommare esattamente a 100. -- Un destinatario non può avere una quota dello 0%. Rimuovilo invece. - -!!! info "Se il tuo accordo con DZF include una condivisione dei ricavi" - Alcuni contributori hanno un accordo che divide le ricompense con la fondazione, ad esempio quando DZF ha fornito l'hardware. Se questo si applica a te, DZF ti fornisce l'indirizzo e la percentuale da inserire qui. Chiedi a DZF se non sei sicuro. - -=== "Portale web" - - 1. Vai su [doublezero.xyz/rewards](https://doublezero.xyz/rewards). Il vecchio indirizzo, `rewards.doublezero.xyz`, reindirizza qui. - 2. Collega il tuo wallet del gestore ricompense con il pulsante wallet in alto a destra. - 3. Seleziona la tua chiave di servizio dalla lista nella pagina successiva. - 4. Inserisci l'indirizzo di ogni wallet destinatario e la sua percentuale. Il totale deve essere 100%. - 5. Clicca **Submit** e approva la transazione nel tuo wallet. - -=== "CLI" - - Esegui questo comando con il keypair del tuo gestore ricompense come `-k`. Ripeti `--recipient` per ogni wallet. - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | Flag | Descrizione | - |------|-------------| - | `--service-key` | La tua chiave di servizio come contributore. Questa nomina l'account ricompense onchain. | - | `--recipient` | Un destinatario nel formato `PUBKEY:PERCENT`. Numeri interi, da 1 a 100, che sommano a 100. Massimo 8. | - | `-k` | Il keypair del tuo gestore ricompense. La transazione fallisce se questo non è il gestore ricompense registrato. | - | `-u` | `mainnet-beta`. | - - Aggiungi `--dry-run` prima se vuoi simulare la transazione senza inviarla. - ---- - -## Passo 4: Verifica che Ogni Destinatario Possa Detenere 2Z - -Il protocollo invia 2Z con un semplice trasferimento di token. **Non** crea l'account token per te. Se un wallet destinatario non ha un account token 2Z, il pagamento per quell'epoca fallisce. - -Il mint 2Z su mainnet è: - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -Elenca gli account token che un wallet già possiede: - -```bash -spl-token accounts --owner -u m -``` - -Se `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` manca da quella lista, crea l'account una volta: - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -Qualsiasi wallet con fondi può pagare per questo. Costa una piccola quantità di SOL e deve essere fatto solo una volta per wallet destinatario. - -!!! note "I wallet che già detengono 2Z vanno bene" - Se il wallet ha già ricevuto 2Z in precedenza, l'account token esiste e puoi saltare questo passaggio. - ---- - -## Passo 5: Verifica - -Controlla cosa è ora registrato onchain: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -Output di esempio: - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -La colonna `ata` è l'account token 2Z in cui ogni destinatario riceverà il pagamento. Verifica che la colonna `proportion` sommi al 100%. - ---- - -## Quando Arrivano le Ricompense - -- Le ricompense vengono calcolate per **epoca DZ**, che è l'epoca del DoubleZero Ledger. Un'epoca DZ dura circa due giorni. -- Il pagamento per un'epoca avviene circa 10 epoche DZ dopo la fine di quell'epoca, quindi circa 20 giorni dopo. Questo ritardo copre la contabilità dell'epoca. -- I pagamenti sono automatici. Non devi reclamarli e non devi eseguire nulla. -- Una volta configurati i destinatari, i pagamenti iniziano ad arrivare entro un paio di giorni man mano che le epoche successive vengono elaborate. Le epoche trascorse prima della configurazione dei destinatari sono una questione separata, vedi [Se Configuri Questo in Ritardo](#se-configuri-questo-in-ritardo). -- Un'epoca DZ e un'epoca Solana non hanno la stessa durata. Questa differenza si accumula nel tempo, quindi di tanto in tanto un'epoca DZ mostra zero ricompense. Questo è normale. - ---- - -## Dove Vedere le Tue Ricompense - -**Vista aggregata.** L'[Economic Hub](https://doublezero.xyz/economic-hub) mostra le ricompense dei contributori a livello di rete. - -**Per epoca.** Chiedi al protocollo cosa ha pagato una determinata epoca DZ: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -L'output elenca ogni contributore con la sua quota, la sua ricompensa in 2Z e se il pagamento è stato effettuato. Cerca il tuo codice contributore nella colonna `contributor`. - -Per vedere in quale epoca DZ si trova attualmente la rete, ometti `-e`: - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "Le epoche recenti non sono ancora finalizzate" - Richiedere un'epoca le cui ricompense non sono ancora state calcolate restituisce `Rewards calculation is not finalized yet`. Prova con un'epoca più vecchia. - ---- - -## Se Configuri Questo in Ritardo - -Le ricompense vengono calcolate per ogni epoca in cui hai contribuito, indipendentemente dal fatto che avessi o meno dei destinatari configurati in quel momento. Queste ricompense non vengono bruciate e non scadono. Restano nell'account di distribuzione di quell'epoca finché qualcuno non invia il pagamento. - -Il problema è che nessuno le invia per te a posteriori. Il processo di pagamento di routine elabora le epoche recenti, quindi un'epoca trascorsa mentre la tua lista destinatari era vuota resta non pagata finché non viene inviata manualmente. - -Per trovare quali epoche sono interessate, cerca le righe con il tuo codice contributore dove `distributed` è `no` e la ricompensa è superiore a zero: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -L'invio del pagamento è permissionless, quindi una volta configurati i destinatari, qualsiasi wallet con fondi può farlo, incluso il tuo: - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -Aggiungi `--dry-run` prima per simulare senza inviare nulla. Il comando elabora ogni contributore in quell'epoca e salta quelli già pagati, quindi è sicuro da eseguire. - -Se preferisci non farlo tu stesso, chiedi a DZF di inviare le epoche per te. - ---- - -## Modificare i Destinatari Successivamente - -Ripeti il [Passo 3](#passo-3-imposta-i-tuoi-wallet-destinatari) in qualsiasi momento. La nuova lista sostituisce completamente quella vecchia, quindi includi ogni destinatario che desideri ancora, non solo quelli che stai aggiungendo. Le percentuali devono sommare di nuovo a 100. - -Ricordati del [Passo 4](#passo-4-verifica-che-ogni-destinatario-possa-detenere-2z) per ogni wallet che aggiungi. - ---- - -## Bloccare la Chiave del Gestore Ricompense - -Per impostazione predefinita DZF può cambiare la tua chiave del gestore ricompense, il che è utile se perdi l'accesso ad essa. Se preferisci escludere questa possibilità, puoi bloccarla: - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "Non bloccare una chiave che potresti perdere" - Una volta bloccata la gestione, nessuno può sostituire la tua chiave del gestore ricompense, inclusa DZF. Se poi perdi quella chiave non potrai più cambiare dove vanno le tue ricompense. Blocca solo se la chiave è salvata in backup e al sicuro. - -Per consentirla di nuovo, esegui lo stesso comando con `--allow-protocol-management`. - ---- - -## Risoluzione dei Problemi - -**La colonna `manager` è vuota.** -DZF non ha ancora registrato la tua chiave del gestore ricompense. Invia loro la chiave pubblica e chiedi conferma. - -**`Invalid rewards manager`.** -Il keypair con cui hai firmato non è il gestore ricompense registrato. Verifica di aver passato il file corretto a `-k`, o il wallet corretto nel portale. - -**`Invalid recipients`.** -Le tue percentuali non sommano esattamente a 100, hai elencato più di 8 destinatari, oppure uno di essi ha una quota dello 0%. - -**Le ricompense risultano guadagnate ma non arriva nulla.** -Due cause comuni. O non sono configurati destinatari, quindi non c'è dove inviarle, oppure un wallet destinatario non ha un account token 2Z. Segui il [Passo 4](#passo-4-verifica-che-ogni-destinatario-possa-detenere-2z) e il [Passo 5](#passo-5-verifica). Una volta risolto, le epoche future vengono pagate automaticamente. Le epoche già trascorse necessitano di [un pagamento manuale](#se-configuri-questo-in-ritardo). - -**Le tue ricompense per un'epoca recente sono 0.** -Le ricompense hanno un ritardo di circa 10 epoche DZ. Controlla un'epoca che sia almeno così vecchia. Epoche occasionali con zero sono anche normali, vedi [Quando Arrivano le Ricompense](#quando-arrivano-le-ricompense). - ---- - -## Prossimi Passi - -Torna alla [Checklist di Onboarding](contribute-overview.md#onboarding-checklist), oppure prosegui con [Operazioni](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.ja.md b/docs/contribute-rewards.ja.md deleted file mode 100644 index 02ccb17..0000000 --- a/docs/contribute-rewards.ja.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: DoubleZero への貢献で獲得した 2Z 報酬が、あなたが管理するウォレットに支払われるようにリワード管理を設定します。 ---- - -# リワード管理 - -あなたが提供する帯域幅やデバイスに対して、[2Z](glossary.md#2z-token) で報酬を獲得できます。プロトコルはこれらの報酬を、あなたが指定したウォレットに直接自動的に支払います。ウォレットを指定するまで、報酬は支払われません。 - -!!! warning "アカウントセットアップ時に行ってください" - リワード管理は、デバイスがトラフィックを処理する前に [フェーズ 2: アカウントセットアップ](contribute-provisioning.md#phase-2-account-setup) で設定してください。 - - この設定を後回しにしても報酬は引き続き蓄積されます。プロトコルは報酬をバーンせず、有効期限もありません。失われるのは自動支払いです。定期的な支払いプロセスは直近のエポックを処理するため、受取人が設定されていない間に過ぎたエポックの報酬は、後から手動で支払う必要があります。[設定が遅れた場合](#if-you-set-this-up-late)を参照してください。 - ---- - -## 仕組み - -3 つの鍵が関係しています。それぞれ異なる役割を持ち、分離して管理する方が安全です。 - -| 鍵 | 役割 | 報酬を受け取る？ | -|-----|--------------|-------------------| -| **サービスキー** | コントリビューターとしてあなたを識別し、CLI コマンドに署名します。また、オンチェーンの報酬アカウントの名前にもなります。 | いいえ | -| **リワードマネージャーキー** | 報酬を受け取るウォレットリストの変更に署名します。 | いいえ | -| **受取ウォレット** | プロトコルから送られる 2Z を保持します。最大 8 ウォレット。 | はい | - -DoubleZero Foundation（DZF）がサービスキーに対してリワードマネージャーキーを登録します。この操作は DZF のみが行えます。登録後は、受取人リストを変更できるのはリワードマネージャーキーだけとなり、DZF があなたの報酬をリダイレクトすることはできません。 - -```mermaid -flowchart LR - DZF["DZF"] -->|"リワードマネージャーキー
を登録"| ACC["あなたの報酬アカウント
（オンチェーン）"] - RM["リワードマネージャーキー
（あなたが保持、オフラインで保管）"] -->|"受取人と
割合を設定"| ACC - ACC --> R1["受取ウォレット 1"] - ACC --> R2["受取ウォレット 2"] - PROTO["プロトコルが各 DZ エポック
ごとに支払い"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## 事前に必要なもの - -- オンチェーンのコントリビューターアカウント。`doublezero contributor list` で確認できます。 -- リワードマネージャーとして使用する Solana ウォレット。トランザクション手数料を支払うために約 0.01 SOL を保持してください。 -- 2Z を受け取るための 1 つ以上のウォレット。 -- ポータルではなくコマンドラインを使用する場合は `doublezero-solana` CLI。`sudo apt update && sudo apt install doublezero-solana` でインストールできます。 - -!!! tip "リワードマネージャーキーにはハードウェアウォレットを使用してください" - リワードマネージャーキーはあなたの資金の送付先を管理します。ハードウェアウォレットまたはその他のオフライン手段で保管してください。サーバー上に置く必要はなく、報酬を保持することもありません。 - ---- - -## ステップ 1: リワードマネージャーウォレットの作成 - -あなたが管理し、署名できる Solana ウォレットを作成します。ハードウェアウォレット、ブラウザウォレット、またはキーペアファイルのいずれでも構いません。 - -少額の SOL（約 0.01 SOL）をチャージしてください。これは受取人リストを変更する際のネットワーク手数料の支払いにのみ使用されます。 - -サービスキーをこの用途で再利用しないでください。サービスキーが管理サーバー上にある場合、そのサーバーにアクセスできる者が報酬の送付先を変更できてしまいます。 - ---- - -## ステップ 2: 公開鍵を DZF に送信 - -リワードマネージャーウォレットの**公開鍵**を DZF に送ります。秘密鍵は絶対に共有しないでください。 - -DZF がオンチェーンであなたのサービスキーに対してそれを登録し、完了を確認します。このステップを自分で行うことはできません。 - -!!! tip "サービスキーと一緒に送信してください" - [デバイスプロビジョニングガイド](contribute-provisioning.md)に沿って作業している場合は、[ステップ 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf) でサービスキーと GitHub ユーザー名と一緒にこの公開鍵を送信してください。DZF は 2 つの鍵を別々のトランザクションで登録するため、同時に送ることでやり取りの往復を節約できます。 - -登録が完了したか確認できます： - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -`manager` 列にリワードマネージャーキーが表示されます。空の場合、DZF がまだ登録していません。 - ---- - -## ステップ 3: 受取ウォレットの設定 - -報酬の送付先を指定します。Web ポータルまたは CLI を使用できます。どちらもオンチェーンに同じ内容を書き込みます。 - -どちらの方法でも適用されるルール： - -- 受取ウォレットは最大 8 つ。 -- 割合は整数で、合計がちょうど 100 になる必要があります。 -- 受取人に 0% のシェアを設定することはできません。代わりに削除してください。 - -!!! info "DZF との契約にレベニューシェアが含まれている場合" - 一部のコントリビューターは、DZF がハードウェアを提供した場合など、報酬をファウンデーションと分配する契約を結んでいます。該当する場合、DZF がここに入力するアドレスと割合を提供します。不明な場合は DZF にお問い合わせください。 - -=== "Web ポータル" - - 1. [doublezero.xyz/rewards](https://doublezero.xyz/rewards) にアクセスします。旧アドレス `rewards.doublezero.xyz` はここにリダイレクトされます。 - 2. 右上のウォレットボタンでリワードマネージャーウォレットを接続します。 - 3. 次のページのリストからサービスキーを選択します。 - 4. 各受取ウォレットのアドレスと割合を入力します。合計は 100% にする必要があります。 - 5. **Submit** をクリックし、ウォレットでトランザクションを承認します。 - -=== "CLI" - - リワードマネージャーのキーペアを `-k` として指定して実行します。ウォレットごとに `--recipient` を繰り返します。 - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | フラグ | 説明 | - |------|-------------| - | `--service-key` | コントリビューターのサービスキー。オンチェーンの報酬アカウントの名前になります。 | - | `--recipient` | `PUBKEY:PERCENT` 形式の受取人。整数、1 から 100、合計 100。最大 8 つ。 | - | `-k` | リワードマネージャーのキーペア。登録されたリワードマネージャーでない場合、トランザクションは失敗します。 | - | `-u` | `mainnet-beta`。 | - - 送信せずにトランザクションをシミュレーションしたい場合は、先に `--dry-run` を追加してください。 - ---- - -## ステップ 4: 各受取人が 2Z を保持できるか確認 - -プロトコルはプレーンなトークン転送で 2Z を送信します。トークンアカウントを自動で作成することは**ありません**。受取ウォレットに 2Z トークンアカウントがない場合、そのエポックの支払いは失敗します。 - -メインネットの 2Z ミントアドレスは： - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -ウォレットが既に持っているトークンアカウントを一覧表示します： - -```bash -spl-token accounts --owner -u m -``` - -`J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` がリストにない場合、一度だけアカウントを作成します： - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -任意の資金が入ったウォレットで支払えます。少額の SOL がかかり、受取ウォレットごとに一度だけ行う必要があります。 - -!!! note "既に 2Z を保持しているウォレットは問題ありません" - そのウォレットが 2Z を受け取ったことがある場合、トークンアカウントは既に存在しているため、このステップはスキップできます。 - ---- - -## ステップ 5: 確認 - -オンチェーンに記録されている内容を確認します： - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -出力例： - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -`ata` 列は各受取人に支払われる 2Z トークンアカウントです。`proportion` 列の合計が 100% になっていることを確認してください。 - ---- - -## 報酬が届くタイミング - -- 報酬は **DZ エポック**（DoubleZero Ledger のエポック）ごとに計算されます。DZ エポックはおよそ 2 日間です。 -- エポックの支払いは、そのエポック終了後約 10 DZ エポック（約 20 日後）に行われます。この遅延はエポックの会計処理をカバーするためです。 -- 支払いは自動的に行われます。請求する必要はなく、何かを実行する必要もありません。 -- 受取人を設定すると、次のエポックが処理されるにつれて数日以内に支払いが届き始めます。受取人を設定する前に過ぎたエポックについては別の問題です。[設定が遅れた場合](#if-you-set-this-up-late)を参照してください。 -- DZ エポックと Solana エポックは長さが異なります。この差は時間とともに蓄積されるため、時折 DZ エポックの報酬がゼロになることがあります。これは正常です。 - ---- - -## 報酬の確認方法 - -**集計ビュー。** [Economic Hub](https://doublezero.xyz/economic-hub) でネットワークレベルのコントリビューター報酬を確認できます。 - -**エポックごと。** 特定の DZ エポックの支払い内容をプロトコルに問い合わせます： - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -出力には、各コントリビューターのシェア、2Z での報酬額、および支払いが行われたかどうかが一覧表示されます。`contributor` 列であなたのコントリビューターコードを見つけてください。 - -現在のネットワークの DZ エポックを確認するには、`-e` を省略します： - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "直近のエポックはまだ確定していません" - 報酬がまだ計算されていないエポックを問い合わせると `Rewards calculation is not finalized yet` と返されます。もっと古いエポックを試してください。 - ---- - -## 設定が遅れた場合 - -報酬は、受取人が設定されていたかどうかに関わらず、あなたが貢献したすべてのエポックについて計算されます。これらの報酬はバーンされず、有効期限もありません。誰かが支払いを送信するまで、そのエポックの分配アカウントに残り続けます。 - -問題は、事後に自動で送信してくれるものがないことです。定期的な支払いプロセスは直近のエポックを処理するため、受取人リストが空の間に過ぎたエポックは、手動で送信されるまで未払いのままです。 - -影響を受けるエポックを見つけるには、あなたのコントリビューターコードで `distributed` が `no` かつ報酬がゼロ以上の行を探します： - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -支払いの送信はパーミッションレスなので、受取人が設定された後は、あなた自身を含む任意の資金が入ったウォレットで実行できます： - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -送信せずにシミュレーションするには、先に `--dry-run` を追加してください。このコマンドはそのエポックのすべてのコントリビューターを処理し、既に支払い済みのものはスキップするため、安全に実行できます。 - -自分で行いたくない場合は、DZF にエポックの送信を依頼してください。 - ---- - -## 受取人の変更 - -いつでも[ステップ 3](#step-3-set-your-recipient-wallets) を繰り返すことができます。新しいリストは古いリストを完全に置き換えるため、追加するものだけでなく、引き続き必要なすべての受取人を含めてください。割合は再び合計 100 にする必要があります。 - -追加するウォレットについては[ステップ 4](#step-4-check-each-recipient-can-hold-2z) を忘れないでください。 - ---- - -## リワードマネージャーキーのロック - -デフォルトでは、DZF はリワードマネージャーキーを変更できます。これはキーへのアクセスを失った場合に便利です。この可能性を排除したい場合は、ブロックできます： - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "失う可能性のあるキーをロックしないでください" - 管理がブロックされると、DZF を含め誰もリワードマネージャーキーを置き換えることができなくなります。そのキーを紛失した場合、報酬の送付先を変更できなくなります。キーがバックアップされ安全に保管されている場合にのみブロックしてください。 - -再び許可するには、同じコマンドを `--allow-protocol-management` で実行します。 - ---- - -## トラブルシューティング - -**`manager` 列が空。** -DZF がまだリワードマネージャーキーを登録していません。公開鍵を送信し、確認を依頼してください。 - -**`Invalid rewards manager`。** -署名に使用したキーペアが登録されたリワードマネージャーではありません。`-k` に正しいファイルを渡したか、ポータルで正しいウォレットを使用しているか確認してください。 - -**`Invalid recipients`。** -割合の合計がちょうど 100 になっていないか、受取人が 8 つを超えているか、いずれかの受取人が 0% のシェアになっています。 - -**報酬は獲得済みと表示されるが届かない。** -一般的な原因が 2 つあります。受取人が設定されていないため送付先がないか、受取ウォレットに 2Z トークンアカウントがないかのいずれかです。[ステップ 4](#step-4-check-each-recipient-can-hold-2z) と[ステップ 5](#step-5-verify) を確認してください。修正後、将来のエポックは自動的に支払われます。既に過ぎたエポックには[手動での支払い](#if-you-set-this-up-late)が必要です。 - -**直近のエポックの報酬が 0。** -報酬には約 10 DZ エポックの遅延があります。少なくともそれだけ古いエポックを確認してください。時折ゼロのエポックが発生するのも正常です。[報酬が届くタイミング](#when-rewards-arrive)を参照してください。 - ---- - -## 次のステップ - -[オンボーディングチェックリスト](contribute-overview.md#onboarding-checklist)に戻るか、[運用](contribute-operations.md)に進んでください。 \ No newline at end of file diff --git a/docs/contribute-rewards.ko.md b/docs/contribute-rewards.ko.md deleted file mode 100644 index 174f1dc..0000000 --- a/docs/contribute-rewards.ko.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: DoubleZero 기여로 획득한 2Z 보상이 본인이 관리하는 지갑으로 지급되도록 보상 관리를 설정하세요. ---- - -# 보상 관리 - -기여한 대역폭과 장치에 대해 [2Z](glossary.md#2z-token)로 보상을 받습니다. 프로토콜은 지정한 지갑으로 직접 보상을 자동 지급합니다. 지갑을 지정하기 전까지는 어떤 보상도 지급되지 않습니다. - -!!! warning "계정 설정 시 이 작업을 수행하세요" - [2단계: 계정 설정](contribute-provisioning.md#phase-2-account-setup)에서 장치가 트래픽을 처리하기 전에 보상 관리를 설정하세요. - - 나중에 설정하더라도 보상은 계속 적립됩니다. 프로토콜은 보상을 소각하지 않으며 만료되지도 않습니다. 잃게 되는 것은 자동 지급입니다: 정기 지급 프로세스는 최근 에포크를 순차적으로 처리하므로, 수신자가 설정되지 않은 상태에서 지나간 에포크의 보상은 이후 수동으로 지급해야 합니다. [늦게 설정한 경우](#if-you-set-this-up-late)를 참조하세요. - ---- - -## 작동 방식 - -세 가지 키가 관련됩니다. 각 키는 서로 다른 역할을 하며, 분리하여 보관하는 것이 더 안전합니다. - -| 키 | 역할 | 보상 수신 여부 | -|-----|--------------|-------------------| -| **서비스 키** | 기여자로서의 신원을 확인하고 CLI 명령에 서명합니다. 또한 온체인에서 보상 계정의 이름이 됩니다. | 아니오 | -| **보상 관리자 키** | 보상을 수신하는 지갑 목록의 변경 사항에 서명합니다. | 아니오 | -| **수신 지갑** | 프로토콜이 보내는 2Z를 보관합니다. 최대 8개 지갑. | 예 | - -DoubleZero Foundation(DZF)이 서비스 키에 보상 관리자 키를 등록합니다. DZF만 이 작업을 수행할 수 있습니다. 등록 이후에는 보상 관리자 키만 수신자 목록을 변경할 수 있으며, DZF는 보상을 다른 곳으로 돌릴 수 없습니다. - -```mermaid -flowchart LR - DZF["DZF"] -->|"보상 관리자 키를
등록"| ACC["온체인 보상 계정"] - RM["보상 관리자 키
(본인 보관, 오프라인 유지)"] -->|"수신자 및
비율 설정"| ACC - ACC --> R1["수신 지갑 1"] - ACC --> R2["수신 지갑 2"] - PROTO["프로토콜이 매 DZ 에포크마다
지급"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## 사전 준비 사항 - -- 온체인 기여자 계정. `doublezero contributor list`로 확인하세요. -- 보상 관리자로 사용할 Solana 지갑. 트랜잭션 수수료 지불을 위해 약 0.01 SOL이 필요합니다. -- 2Z를 수신할 하나 이상의 지갑. -- 포털 대신 명령줄을 사용하려면 `doublezero-solana` CLI가 필요합니다. `sudo apt update && sudo apt install doublezero-solana`로 설치하세요. - -!!! tip "보상 관리자 키에는 하드웨어 지갑을 사용하세요" - 보상 관리자 키는 보상이 어디로 전송되는지를 제어합니다. 하드웨어 지갑에 보관하거나 오프라인으로 유지하세요. 서버에 놓아둘 필요가 없으며, 보상을 직접 보관하지도 않습니다. - ---- - -## 1단계: 보상 관리자 지갑 생성 - -본인이 관리하고 서명할 수 있는 Solana 지갑을 생성하세요. 하드웨어 지갑, 브라우저 지갑 또는 키페어 파일이 될 수 있습니다. - -약 0.01 SOL 정도의 소량의 SOL을 충전하세요. 이는 수신자 목록을 변경할 때 네트워크 수수료를 지불하는 데만 사용됩니다. - -이 용도로 서비스 키를 재사용하지 마세요. 서비스 키가 관리 서버에 있는 경우, 해당 서버에 접근하는 누구든 보상을 다른 곳으로 돌릴 수 있습니다. - ---- - -## 2단계: 공개 키를 DZF에 전송 - -보상 관리자 지갑의 **공개 키**를 DZF에 전달하세요. 개인 키는 절대 공유하지 마세요. - -DZF가 서비스 키에 대해 온체인으로 등록하고 완료되면 확인해 줍니다. 이 단계는 직접 수행할 수 없습니다. - -!!! tip "서비스 키와 함께 전송하세요" - [장치 프로비저닝 가이드](contribute-provisioning.md)를 따라 진행 중이라면, [2.4단계](contribute-provisioning.md#step-24-submit-keys-to-dzf)에서 서비스 키 및 GitHub 사용자명과 함께 이 공개 키를 전송하세요. DZF는 두 키를 별도의 트랜잭션으로 등록하므로, 함께 보내면 왕복 과정을 줄일 수 있습니다. - -등록 확인 방법: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -`manager` 열에 보상 관리자 키가 표시됩니다. 비어 있다면 DZF가 아직 등록하지 않은 것입니다. - ---- - -## 3단계: 수신 지갑 설정 - -보상이 어디로 전송되어야 하는지 지정합니다. 웹 포털 또는 CLI를 사용할 수 있습니다. 둘 다 동일한 내용을 온체인에 기록합니다. - -두 방법 모두에 적용되는 규칙: - -- 수신 지갑은 최대 8개. -- 비율은 정수여야 하며 합계가 정확히 100이어야 합니다. -- 수신자의 비율을 0%로 설정할 수 없습니다. 대신 제거하세요. - -!!! info "DZF와의 계약에 수익 분배가 포함된 경우" - 일부 기여자는 재단과 보상을 분배하는 계약을 맺고 있습니다. 예를 들어 DZF가 하드웨어를 제공한 경우입니다. 해당되는 경우 DZF가 여기에 입력할 주소와 비율을 알려줍니다. 확실하지 않으면 DZF에 문의하세요. - -=== "웹 포털" - - 1. [doublezero.xyz/rewards](https://doublezero.xyz/rewards)로 이동하세요. 이전 주소인 `rewards.doublezero.xyz`는 여기로 리디렉션됩니다. - 2. 오른쪽 상단의 지갑 버튼으로 보상 관리자 지갑을 연결하세요. - 3. 다음 페이지의 목록에서 서비스 키를 선택하세요. - 4. 각 수신 지갑 주소와 비율을 입력하세요. 합계는 100%여야 합니다. - 5. **Submit**을 클릭하고 지갑에서 트랜잭션을 승인하세요. - -=== "CLI" - - 보상 관리자 키페어를 `-k`로 지정하여 실행하세요. 각 지갑마다 `--recipient`를 반복하세요. - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | 플래그 | 설명 | - |------|-------------| - | `--service-key` | 기여자 서비스 키. 온체인에서 보상 계정의 이름이 됩니다. | - | `--recipient` | `PUBKEY:PERCENT` 형식의 수신자. 정수, 1~100, 합계 100. 최대 8개. | - | `-k` | 보상 관리자 키페어. 등록된 보상 관리자가 아니면 트랜잭션이 실패합니다. | - | `-u` | `mainnet-beta`. | - - 트랜잭션을 전송하지 않고 시뮬레이션하려면 먼저 `--dry-run`을 추가하세요. - ---- - -## 4단계: 각 수신 지갑이 2Z를 보관할 수 있는지 확인 - -프로토콜은 일반 토큰 전송으로 2Z를 보냅니다. 토큰 계정을 대신 생성해 주지 **않습니다**. 수신 지갑에 2Z 토큰 계정이 없으면 해당 에포크의 지급이 실패합니다. - -메인넷의 2Z 민트 주소: - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -지갑이 이미 보유한 토큰 계정 목록 확인: - -```bash -spl-token accounts --owner -u m -``` - -`J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd`가 목록에 없으면 한 번만 계정을 생성하세요: - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -잔액이 있는 아무 지갑이나 이 비용을 지불할 수 있습니다. 소량의 SOL이 필요하며 수신 지갑당 한 번만 수행하면 됩니다. - -!!! note "이미 2Z를 보유한 지갑은 괜찮습니다" - 지갑이 이전에 2Z를 수신한 적이 있다면 토큰 계정이 이미 존재하므로 이 단계를 건너뛸 수 있습니다. - ---- - -## 5단계: 확인 - -온체인에 기록된 내용을 확인하세요: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -출력 예시: - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -`ata` 열은 각 수신자가 보상을 받을 2Z 토큰 계정입니다. `proportion` 열의 합계가 100%인지 확인하세요. - ---- - -## 보상 도착 시점 - -- 보상은 **DZ 에포크**(DoubleZero Ledger의 에포크) 단위로 산정됩니다. DZ 에포크는 약 2일 주기입니다. -- 에포크에 대한 지급은 해당 에포크 종료 후 약 10 DZ 에포크(약 20일 후)에 이루어집니다. 이 지연은 에포크에 대한 정산 기간입니다. -- 지급은 자동입니다. 청구할 필요도, 별도로 실행할 것도 없습니다. -- 수신자가 설정되면 다음 에포크가 처리되면서 며칠 내에 지급이 시작됩니다. 수신자를 설정하기 전에 지나간 에포크는 별도의 문제입니다. [늦게 설정한 경우](#if-you-set-this-up-late)를 참조하세요. -- DZ 에포크와 Solana 에포크는 길이가 같지 않습니다. 이 차이가 시간이 지남에 따라 누적되므로 가끔 DZ 에포크의 보상이 0으로 표시됩니다. 이는 정상입니다. - ---- - -## 보상 확인 방법 - -**종합 뷰.** [Economic Hub](https://doublezero.xyz/economic-hub)에서 네트워크 수준의 기여자 보상을 확인할 수 있습니다. - -**에포크별.** 특정 DZ 에포크의 지급 내역을 프로토콜에 조회합니다: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -출력에는 모든 기여자의 지분, 2Z 보상 금액, 지급 완료 여부가 나열됩니다. `contributor` 열에서 본인의 기여자 코드를 찾으세요. - -현재 네트워크의 DZ 에포크를 확인하려면 `-e`를 생략하세요: - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "최근 에포크는 아직 확정되지 않았습니다" - 보상이 아직 산정되지 않은 에포크를 조회하면 `Rewards calculation is not finalized yet`이 반환됩니다. 더 오래된 에포크를 조회하세요. - ---- - -## 늦게 설정한 경우 - -보상은 수신자 설정 여부와 관계없이 기여한 모든 에포크에 대해 산정됩니다. 이 보상은 소각되지 않으며 만료되지도 않습니다. 누군가가 지급을 제출할 때까지 해당 에포크의 분배 계정에 남아 있습니다. - -문제는 사후에 자동으로 제출해 주는 것이 없다는 점입니다. 정기 지급 프로세스는 최근 에포크를 처리하므로, 수신자 목록이 비어 있는 동안 지나간 에포크는 수동으로 제출하기 전까지 미지급 상태로 남습니다. - -영향을 받는 에포크를 찾으려면 기여자 코드가 있는 행 중 `distributed`가 `no`이고 보상이 0보다 큰 행을 찾으세요: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -지급 제출은 권한 없이 누구나 할 수 있으므로, 수신자가 설정된 후에는 잔액이 있는 아무 지갑이나(본인 지갑 포함) 수행할 수 있습니다: - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -전송하지 않고 시뮬레이션하려면 먼저 `--dry-run`을 추가하세요. 이 명령은 해당 에포크의 모든 기여자를 처리하고 이미 지급된 것은 건너뛰므로 안전하게 실행할 수 있습니다. - -직접 하고 싶지 않다면 DZF에 해당 에포크의 제출을 요청하세요. - ---- - -## 수신자 나중에 변경하기 - -언제든지 [3단계](#step-3-set-your-recipient-wallets)를 반복하세요. 새 목록이 기존 목록을 완전히 대체하므로, 추가하는 수신자뿐만 아니라 유지하려는 모든 수신자를 포함하세요. 비율은 다시 합계가 100이어야 합니다. - -추가하는 모든 지갑에 대해 [4단계](#step-4-check-each-recipient-can-hold-2z)를 확인하세요. - ---- - -## 보상 관리자 키 잠금 - -기본적으로 DZF는 보상 관리자 키를 변경할 수 있으며, 이는 키에 대한 접근 권한을 잃었을 때 유용합니다. 이를 차단하고 싶다면 다음과 같이 잠글 수 있습니다: - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "분실할 수 있는 키를 잠그지 마세요" - 관리가 차단되면 DZF를 포함하여 아무도 보상 관리자 키를 교체할 수 없습니다. 이후 해당 키를 분실하면 보상 전송 대상을 더 이상 변경할 수 없습니다. 키가 백업되어 있고 안전한 경우에만 잠그세요. - -다시 허용하려면 동일한 명령에 `--allow-protocol-management`을 사용하세요. - ---- - -## 문제 해결 - -**`manager` 열이 비어 있음.** -DZF가 아직 보상 관리자 키를 등록하지 않았습니다. 공개 키를 보내고 확인을 요청하세요. - -**`Invalid rewards manager`.** -서명에 사용한 키페어가 등록된 보상 관리자가 아닙니다. `-k`에 올바른 파일을 전달했는지, 또는 포털에서 올바른 지갑을 사용했는지 확인하세요. - -**`Invalid recipients`.** -비율의 합계가 정확히 100이 아니거나, 수신자가 8개를 초과했거나, 수신자 중 0% 지분이 있습니다. - -**보상이 적립되었으나 아무것도 도착하지 않음.** -두 가지 일반적인 원인이 있습니다. 수신자가 설정되지 않아 보낼 곳이 없거나, 수신 지갑에 2Z 토큰 계정이 없는 경우입니다. [4단계](#step-4-check-each-recipient-can-hold-2z)와 [5단계](#step-5-verify)를 확인하세요. 문제가 해결되면 이후 에포크는 자동으로 지급됩니다. 이미 지나간 에포크는 [수동 지급](#if-you-set-this-up-late)이 필요합니다. - -**최근 에포크의 보상이 0임.** -보상에는 약 10 DZ 에포크의 지연이 있습니다. 최소 그 이상 경과한 에포크를 확인하세요. 간헐적인 0 에포크도 정상입니다. [보상 도착 시점](#when-rewards-arrive)을 참조하세요. - ---- - -## 다음 단계 - -[온보딩 체크리스트](contribute-overview.md#onboarding-checklist)로 돌아가거나, [운영](contribute-operations.md)으로 진행하세요. \ No newline at end of file diff --git a/docs/contribute-rewards.md b/docs/contribute-rewards.md deleted file mode 100644 index 2039c55..0000000 --- a/docs/contribute-rewards.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: Set up rewards management so the 2Z rewards earned by your DoubleZero contribution are paid to wallets you control. ---- - -# Rewards Management - -You earn rewards in [2Z](glossary.md#2z-token) for the bandwidth and devices you contribute. The protocol pays those rewards out on its own, straight to wallets you nominate. Until you nominate them, nothing can be paid out. - -!!! warning "Do this during account setup" - Set up rewards management in [Phase 2: Account Setup](contribute-provisioning.md#phase-2-account-setup), before your device carries traffic. - - Your rewards still accrue if you leave this until later. The protocol does not burn them and they do not expire. What you lose is the automatic payout: the routine payout process works through recent epochs, so any epoch that passes while you have no recipients set has to be paid out by hand afterwards. See [If You Set This Up Late](#if-you-set-this-up-late). - ---- - -## How It Works - -Three keys are involved. Each does a different job, and it is safer to keep them separate. - -| Key | What it does | Receives rewards? | -|-----|--------------|-------------------| -| **Service key** | Identifies you as a contributor and signs your CLI commands. Also names your rewards account onchain. | No | -| **Rewards manager key** | Signs changes to the list of wallets that receive rewards. | No | -| **Recipient wallet(s)** | Holds the 2Z the protocol sends you. Up to 8 wallets. | Yes | - -The DoubleZero Foundation registers your rewards manager key against your service key. Only DZF can do that. After that, only your rewards manager key can change the recipient list, and DZF cannot redirect your rewards. - -```mermaid -flowchart LR - DZF["DZF"] -->|"Registers your
rewards manager key"| ACC["Your rewards account
onchain"] - RM["Rewards manager key
(you hold, keep offline)"] -->|"Sets recipients
and percentages"| ACC - ACC --> R1["Recipient wallet 1"] - ACC --> R2["Recipient wallet 2"] - PROTO["Protocol pays out
each DZ epoch"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## What You Need First - -- A contributor account onchain. Check with `doublezero contributor list`. -- A Solana wallet to act as your rewards manager, holding about 0.01 SOL to pay transaction fees. -- One or more wallets to receive the 2Z. -- The `doublezero-solana` CLI, if you want to use the command line instead of the portal. Install it with `sudo apt update && sudo apt install doublezero-solana`. - -!!! tip "Use a hardware wallet for the rewards manager key" - The rewards manager key controls where your money goes. Keep it on a hardware wallet or otherwise offline. It never needs to sit on a server, and it never holds your rewards. - ---- - -## Step 1: Create Your Rewards Manager Wallet - -Create a Solana wallet you control and can sign with. This can be a hardware wallet, a browser wallet, or a keypair file. - -Fund it with a small amount of SOL, around 0.01 SOL. This only pays network fees when you change your recipient list. - -Do not reuse your service key for this. If the service key sits on a management server, anyone who reaches that server could redirect your rewards. - ---- - -## Step 2: Send the Public Key to DZF - -Give DZF the **public key** of your rewards manager wallet. Never share the private key. - -DZF registers it against your service key onchain and confirms when it is done. You cannot do this step yourself. - -!!! tip "Send it with your service key" - If you are working through the [Device Provisioning Guide](contribute-provisioning.md), send this public key at the same time as your service key and GitHub username, in [Step 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). DZF registers the two keys in separate transactions, so sending them together saves a round trip. - -You can check it landed: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -The `manager` column shows your rewards manager key. If it is empty, DZF has not registered it yet. - ---- - -## Step 3: Set Your Recipient Wallets - -Now say where the rewards should go. You can use the web portal or the CLI. Both write the same thing onchain. - -Rules that apply either way: - -- At most 8 recipient wallets. -- Percentages must be whole numbers and must add up to exactly 100. -- A recipient cannot have a 0% share. Remove it instead. - -!!! info "If your agreement with DZF includes a revenue share" - Some contributors have an agreement that splits rewards with the foundation, for example where DZF supplied the hardware. If that applies to you, DZF gives you the address and the percentage to enter here. Ask DZF if you are unsure. - -=== "Web portal" - - 1. Go to [doublezero.xyz/rewards](https://doublezero.xyz/rewards). The old address, `rewards.doublezero.xyz`, redirects here. - 2. Connect your rewards manager wallet with the wallet button in the top right. - 3. Select your service key from the list on the next page. - 4. Enter each recipient wallet address and its percentage. The total must be 100%. - 5. Click **Submit** and approve the transaction in your wallet. - -=== "CLI" - - Run this with your rewards manager keypair as `-k`. Repeat `--recipient` for each wallet. - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | Flag | Description | - |------|-------------| - | `--service-key` | Your contributor service key. This names the rewards account onchain. | - | `--recipient` | A recipient in the form `PUBKEY:PERCENT`. Whole numbers, 1 to 100, adding up to 100. Maximum 8. | - | `-k` | Your rewards manager keypair. The transaction fails if this is not the registered rewards manager. | - | `-u` | `mainnet-beta`. | - - Add `--dry-run` first if you want to simulate the transaction without sending it. - ---- - -## Step 4: Check Each Recipient Can Hold 2Z - -The protocol sends 2Z with a plain token transfer. It does **not** create the token account for you. If a recipient wallet has no 2Z token account, the payout for that epoch fails. - -The 2Z mint on mainnet is: - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -List the token accounts a wallet already has: - -```bash -spl-token accounts --owner -u m -``` - -If `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` is missing from that list, create the account once: - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -Any funded wallet can pay for this. It costs a small amount of SOL and only has to be done once per recipient wallet. - -!!! note "Wallets that already hold 2Z are fine" - If the wallet has ever received 2Z, the token account exists and you can skip this step. - ---- - -## Step 5: Verify - -Check what is now recorded onchain: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -Example output: - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -The `ata` column is the 2Z token account each recipient will be paid into. Check the `proportion` column adds up to 100%. - ---- - -## When Rewards Arrive - -- Rewards are worked out per **DZ epoch**, which is the epoch of the DoubleZero Ledger. A DZ epoch runs roughly two days. -- Payout for an epoch happens around 10 DZ epochs after that epoch ends, so about 20 days later. This lag covers the accounting for the epoch. -- Payouts are automatic. You do not claim them, and you do not need to run anything. -- Once your recipients are set, payouts start arriving within a couple of days as the next epochs are worked through. Epochs that passed before you set your recipients are a separate matter, see [If You Set This Up Late](#if-you-set-this-up-late). -- A DZ epoch and a Solana epoch are not the same length. That difference adds up over time, so now and then a DZ epoch shows zero rewards. This is expected. - ---- - -## Where to See Your Rewards - -**Aggregate view.** The [Economic Hub](https://doublezero.xyz/economic-hub) shows contributor rewards at a network level. - -**Per epoch.** Ask the protocol what a given DZ epoch paid out: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -The output lists every contributor with its share, its reward in 2Z, and whether the payout has been made. Find your contributor code in the `contributor` column. - -To see which DZ epoch the network is on now, leave `-e` off: - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "Recent epochs are not final yet" - Asking for an epoch whose rewards have not been worked out yet returns `Rewards calculation is not finalized yet`. Try an older epoch. - ---- - -## If You Set This Up Late - -Rewards are worked out for every epoch you contributed, whether or not you had recipients configured at the time. Those rewards are not burned and they do not expire. They sit in that epoch's distribution account until someone submits the payout. - -The catch is that nothing submits them for you after the fact. The routine payout process works through recent epochs, so an epoch that passed while your recipient list was empty stays unpaid until it is submitted by hand. - -To find which epochs are affected, look for rows with your contributor code where `distributed` is `no` and the reward is above zero: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -Submitting the payout is permissionless, so once your recipients are configured, any funded wallet can do it, including your own: - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -Add `--dry-run` first to simulate it without sending anything. The command works through every contributor in that epoch and skips the ones already paid, so it is safe to run. - -If you would rather not do this yourself, ask DZF to submit the epochs for you. - ---- - -## Changing Recipients Later - -Repeat [Step 3](#step-3-set-your-recipient-wallets) at any time. The new list replaces the old one in full, so include every recipient you still want, not just the ones you are adding. Percentages must add up to 100 again. - -Remember [Step 4](#step-4-check-each-recipient-can-hold-2z) for any wallet you add. - ---- - -## Locking the Rewards Manager Key - -By default DZF can change your rewards manager key, which is useful if you lose access to it. If you would rather rule that out, you can block it: - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "Do not lock a key you might lose" - Once management is blocked, nobody can replace your rewards manager key, including DZF. If you then lose that key you can no longer change where your rewards go. Only block it if the key is backed up and safe. - -To allow it again, run the same command with `--allow-protocol-management`. - ---- - -## Troubleshooting - -**The `manager` column is empty.** -DZF has not registered your rewards manager key yet. Send them the public key and ask them to confirm. - -**`Invalid rewards manager`.** -The keypair you signed with is not the registered rewards manager. Check you passed the right file to `-k`, or the right wallet in the portal. - -**`Invalid recipients`.** -Your percentages do not add up to exactly 100, you listed more than 8 recipients, or one of them has a 0% share. - -**Rewards show as earned but nothing arrives.** -Two common causes. Either no recipients are configured, so there is nowhere to send them, or a recipient wallet has no 2Z token account. Work through [Step 4](#step-4-check-each-recipient-can-hold-2z) and [Step 5](#step-5-verify). Once that is fixed, future epochs pay out on their own. Epochs that already passed need [a manual payout](#if-you-set-this-up-late). - -**Your rewards for a recent epoch are 0.** -Rewards lag by about 10 DZ epochs. Check an epoch that is at least that old. Occasional zero epochs are also normal, see [When Rewards Arrive](#when-rewards-arrive). - ---- - -## Next Steps - -Back to the [Onboarding Checklist](contribute-overview.md#onboarding-checklist), or on to [Operations](contribute-operations.md). diff --git a/docs/contribute-rewards.pt.md b/docs/contribute-rewards.pt.md deleted file mode 100644 index 6e36ea2..0000000 --- a/docs/contribute-rewards.pt.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: Configure a gestão de recompensas para que as recompensas em 2Z obtidas pela sua contribuição ao DoubleZero sejam pagas nas carteiras que você controla. ---- - -# Gestão de Recompensas - -Você ganha recompensas em [2Z](glossary.md#2z-token) pela largura de banda e dispositivos que contribui. O protocolo paga essas recompensas por conta própria, diretamente nas carteiras que você indicar. Até que você as indique, nada poderá ser pago. - -!!! warning "Faça isso durante a configuração da conta" - Configure a gestão de recompensas na [Fase 2: Configuração da Conta](contribute-provisioning.md#phase-2-account-setup), antes que seu dispositivo transporte tráfego. - - Suas recompensas ainda acumulam se você deixar isso para depois. O protocolo não as queima e elas não expiram. O que você perde é o pagamento automático: o processo de pagamento rotineiro percorre as épocas recentes, então qualquer época que passe enquanto você não tiver destinatários configurados terá que ser paga manualmente depois. Veja [Se Você Configurar Isso com Atraso](#se-voce-configurar-isso-com-atraso). - ---- - -## Como Funciona - -Três chaves estão envolvidas. Cada uma tem uma função diferente, e é mais seguro mantê-las separadas. - -| Chave | O que faz | Recebe recompensas? | -|-------|-----------|---------------------| -| **Chave de serviço** | Identifica você como contribuidor e assina seus comandos CLI. Também nomeia sua conta de recompensas onchain. | Não | -| **Chave do gerenciador de recompensas** | Assina alterações na lista de carteiras que recebem recompensas. | Não | -| **Carteira(s) destinatária(s)** | Mantém os 2Z que o protocolo envia a você. Até 8 carteiras. | Sim | - -A DoubleZero Foundation registra sua chave do gerenciador de recompensas vinculada à sua chave de serviço. Apenas a DZF pode fazer isso. Depois disso, apenas sua chave do gerenciador de recompensas pode alterar a lista de destinatários, e a DZF não pode redirecionar suas recompensas. - -```mermaid -flowchart LR - DZF["DZF"] -->|"Registra sua
chave do gerenciador de recompensas"| ACC["Sua conta de recompensas
onchain"] - RM["Chave do gerenciador de recompensas
(você mantém, guarde offline)"] -->|"Define destinatários
e percentuais"| ACC - ACC --> R1["Carteira destinatária 1"] - ACC --> R2["Carteira destinatária 2"] - PROTO["Protocolo paga
a cada época DZ"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## O Que Você Precisa Primeiro - -- Uma conta de contribuidor onchain. Verifique com `doublezero contributor list`. -- Uma carteira Solana para atuar como seu gerenciador de recompensas, com cerca de 0,01 SOL para pagar taxas de transação. -- Uma ou mais carteiras para receber os 2Z. -- O CLI `doublezero-solana`, se você quiser usar a linha de comando em vez do portal. Instale com `sudo apt update && sudo apt install doublezero-solana`. - -!!! tip "Use uma carteira de hardware para a chave do gerenciador de recompensas" - A chave do gerenciador de recompensas controla para onde seu dinheiro vai. Mantenha-a em uma carteira de hardware ou de outra forma offline. Ela nunca precisa ficar em um servidor, e nunca mantém suas recompensas. - ---- - -## Passo 1: Crie Sua Carteira do Gerenciador de Recompensas - -Crie uma carteira Solana que você controle e com a qual possa assinar. Pode ser uma carteira de hardware, uma carteira de navegador ou um arquivo de par de chaves. - -Financie-a com uma pequena quantidade de SOL, cerca de 0,01 SOL. Isso serve apenas para pagar taxas de rede quando você alterar sua lista de destinatários. - -Não reutilize sua chave de serviço para isso. Se a chave de serviço estiver em um servidor de gerenciamento, qualquer pessoa que acessar esse servidor poderá redirecionar suas recompensas. - ---- - -## Passo 2: Envie a Chave Pública para a DZF - -Forneça à DZF a **chave pública** da sua carteira do gerenciador de recompensas. Nunca compartilhe a chave privada. - -A DZF a registra vinculada à sua chave de serviço onchain e confirma quando estiver concluído. Você não pode fazer este passo sozinho. - -!!! tip "Envie junto com sua chave de serviço" - Se você está seguindo o [Guia de Provisionamento de Dispositivos](contribute-provisioning.md), envie esta chave pública ao mesmo tempo que sua chave de serviço e nome de usuário do GitHub, no [Passo 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf). A DZF registra as duas chaves em transações separadas, então enviá-las juntas economiza uma ida e volta. - -Você pode verificar se foi registrada: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -A coluna `manager` mostra sua chave do gerenciador de recompensas. Se estiver vazia, a DZF ainda não a registrou. - ---- - -## Passo 3: Defina Suas Carteiras Destinatárias - -Agora indique para onde as recompensas devem ir. Você pode usar o portal web ou o CLI. Ambos gravam a mesma coisa onchain. - -Regras que se aplicam em ambos os casos: - -- No máximo 8 carteiras destinatárias. -- Os percentuais devem ser números inteiros e devem somar exatamente 100. -- Um destinatário não pode ter uma participação de 0%. Remova-o em vez disso. - -!!! info "Se seu acordo com a DZF inclui compartilhamento de receita" - Alguns contribuidores têm um acordo que divide as recompensas com a fundação, por exemplo quando a DZF forneceu o hardware. Se isso se aplica a você, a DZF fornece o endereço e o percentual a inserir aqui. Pergunte à DZF se não tiver certeza. - -=== "Portal web" - - 1. Acesse [doublezero.xyz/rewards](https://doublezero.xyz/rewards). O endereço antigo, `rewards.doublezero.xyz`, redireciona para cá. - 2. Conecte sua carteira do gerenciador de recompensas com o botão de carteira no canto superior direito. - 3. Selecione sua chave de serviço na lista da página seguinte. - 4. Insira cada endereço de carteira destinatária e seu percentual. O total deve ser 100%. - 5. Clique em **Submit** e aprove a transação na sua carteira. - -=== "CLI" - - Execute isso com seu par de chaves do gerenciador de recompensas como `-k`. Repita `--recipient` para cada carteira. - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | Flag | Descrição | - |------|-----------| - | `--service-key` | Sua chave de serviço de contribuidor. Ela nomeia a conta de recompensas onchain. | - | `--recipient` | Um destinatário no formato `PUBKEY:PERCENT`. Números inteiros, de 1 a 100, somando 100. Máximo de 8. | - | `-k` | Seu par de chaves do gerenciador de recompensas. A transação falha se este não for o gerenciador de recompensas registrado. | - | `-u` | `mainnet-beta`. | - - Adicione `--dry-run` primeiro se quiser simular a transação sem enviá-la. - ---- - -## Passo 4: Verifique Se Cada Destinatário Pode Manter 2Z - -O protocolo envia 2Z com uma transferência de token simples. Ele **não** cria a conta de token para você. Se uma carteira destinatária não tiver uma conta de token 2Z, o pagamento daquela época falha. - -O mint do 2Z na mainnet é: - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -Liste as contas de token que uma carteira já possui: - -```bash -spl-token accounts --owner -u m -``` - -Se `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` não estiver nessa lista, crie a conta uma vez: - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -Qualquer carteira financiada pode pagar por isso. Custa uma pequena quantidade de SOL e só precisa ser feito uma vez por carteira destinatária. - -!!! note "Carteiras que já possuem 2Z estão ok" - Se a carteira já recebeu 2Z alguma vez, a conta de token existe e você pode pular este passo. - ---- - -## Passo 5: Verifique - -Confira o que está agora registrado onchain: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -Exemplo de saída: - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -A coluna `ata` é a conta de token 2Z na qual cada destinatário será pago. Verifique se a coluna `proportion` soma 100%. - ---- - -## Quando as Recompensas Chegam - -- As recompensas são calculadas por **época DZ**, que é a época do DoubleZero Ledger. Uma época DZ dura aproximadamente dois dias. -- O pagamento de uma época acontece cerca de 10 épocas DZ após o término daquela época, ou seja, aproximadamente 20 dias depois. Esse atraso cobre a contabilidade da época. -- Os pagamentos são automáticos. Você não precisa reivindicá-los e não precisa executar nada. -- Uma vez que seus destinatários estejam configurados, os pagamentos começam a chegar dentro de alguns dias conforme as próximas épocas são processadas. Épocas que passaram antes de você configurar seus destinatários são um assunto separado, veja [Se Você Configurar Isso com Atraso](#se-voce-configurar-isso-com-atraso). -- Uma época DZ e uma época Solana não têm a mesma duração. Essa diferença se acumula ao longo do tempo, então de vez em quando uma época DZ mostra zero recompensas. Isso é esperado. - ---- - -## Onde Ver Suas Recompensas - -**Visão agregada.** O [Economic Hub](https://doublezero.xyz/economic-hub) mostra as recompensas dos contribuidores em nível de rede. - -**Por época.** Pergunte ao protocolo o que uma determinada época DZ pagou: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -A saída lista cada contribuidor com sua participação, sua recompensa em 2Z e se o pagamento foi realizado. Encontre seu código de contribuidor na coluna `contributor`. - -Para ver em qual época DZ a rede está agora, omita `-e`: - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "Épocas recentes ainda não estão finalizadas" - Consultar uma época cujas recompensas ainda não foram calculadas retorna `Rewards calculation is not finalized yet`. Tente uma época mais antiga. - ---- - -## Se Você Configurar Isso com Atraso - -As recompensas são calculadas para cada época em que você contribuiu, independentemente de ter destinatários configurados no momento. Essas recompensas não são queimadas e não expiram. Elas ficam na conta de distribuição daquela época até que alguém submeta o pagamento. - -O problema é que nada as submete por você depois do fato. O processo de pagamento rotineiro percorre épocas recentes, então uma época que passou enquanto sua lista de destinatários estava vazia permanece sem pagamento até ser submetida manualmente. - -Para descobrir quais épocas foram afetadas, procure linhas com seu código de contribuidor onde `distributed` é `no` e a recompensa é maior que zero: - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -Submeter o pagamento é permissionless, então uma vez que seus destinatários estejam configurados, qualquer carteira financiada pode fazer isso, incluindo a sua: - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -Adicione `--dry-run` primeiro para simular sem enviar nada. O comando percorre todos os contribuidores daquela época e pula os que já foram pagos, então é seguro executá-lo. - -Se você preferir não fazer isso sozinho, peça à DZF para submeter as épocas por você. - ---- - -## Alterando Destinatários Posteriormente - -Repita o [Passo 3](#passo-3-defina-suas-carteiras-destinatarias) a qualquer momento. A nova lista substitui a antiga completamente, então inclua todos os destinatários que você ainda deseja, não apenas os que está adicionando. Os percentuais devem somar 100 novamente. - -Lembre-se do [Passo 4](#passo-4-verifique-se-cada-destinatario-pode-manter-2z) para qualquer carteira que adicionar. - ---- - -## Bloqueando a Chave do Gerenciador de Recompensas - -Por padrão, a DZF pode alterar sua chave do gerenciador de recompensas, o que é útil caso você perca o acesso a ela. Se você preferir descartar essa possibilidade, pode bloqueá-la: - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "Não bloqueie uma chave que você pode perder" - Uma vez que o gerenciamento é bloqueado, ninguém pode substituir sua chave do gerenciador de recompensas, incluindo a DZF. Se você então perder essa chave, não poderá mais alterar para onde suas recompensas vão. Só bloqueie se a chave estiver com backup e segura. - -Para permitir novamente, execute o mesmo comando com `--allow-protocol-management`. - ---- - -## Solução de Problemas - -**A coluna `manager` está vazia.** -A DZF ainda não registrou sua chave do gerenciador de recompensas. Envie a chave pública e peça confirmação. - -**`Invalid rewards manager`.** -O par de chaves com o qual você assinou não é o gerenciador de recompensas registrado. Verifique se passou o arquivo correto para `-k`, ou a carteira correta no portal. - -**`Invalid recipients`.** -Seus percentuais não somam exatamente 100, você listou mais de 8 destinatários, ou um deles tem participação de 0%. - -**As recompensas aparecem como ganhas, mas nada chega.** -Duas causas comuns. Ou nenhum destinatário está configurado, então não há para onde enviá-las, ou uma carteira destinatária não possui conta de token 2Z. Siga o [Passo 4](#passo-4-verifique-se-cada-destinatario-pode-manter-2z) e o [Passo 5](#passo-5-verifique). Uma vez corrigido, épocas futuras serão pagas automaticamente. Épocas que já passaram precisam de [pagamento manual](#se-voce-configurar-isso-com-atraso). - -**Suas recompensas para uma época recente são 0.** -As recompensas têm um atraso de cerca de 10 épocas DZ. Verifique uma época que tenha pelo menos essa idade. Épocas ocasionais com zero também são normais, veja [Quando as Recompensas Chegam](#quando-as-recompensas-chegam). - ---- - -## Próximos Passos - -Volte para a [Lista de Verificação de Integração](contribute-overview.md#onboarding-checklist), ou prossiga para [Operações](contribute-operations.md). \ No newline at end of file diff --git a/docs/contribute-rewards.zh.md b/docs/contribute-rewards.zh.md deleted file mode 100644 index 33ca286..0000000 --- a/docs/contribute-rewards.zh.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -description: 设置奖励管理，以便您通过 DoubleZero 贡献所赚取的 2Z 奖励支付到您控制的钱包。 ---- - -# 奖励管理 - -您通过贡献带宽和设备赚取 [2Z](glossary.md#2z-token) 奖励。协议会自动将这些奖励直接支付到您指定的钱包。在您指定钱包之前，奖励无法支付。 - -!!! warning "请在账户设置期间完成此操作" - 请在 [阶段 2：账户设置](contribute-provisioning.md#phase-2-account-setup) 中设置奖励管理，在您的设备开始承载流量之前完成。 - - 如果您推迟此操作，奖励仍会累积。协议不会销毁它们，它们也不会过期。您损失的是自动支付：常规支付流程只处理近期的纪元，因此在您未设置收款方期间经过的任何纪元都需要事后手动支付。请参阅 [如果您设置较晚](#if-you-set-this-up-late)。 - ---- - -## 工作原理 - -涉及三个密钥。每个密钥执行不同的功能，将它们分开保管更为安全。 - -| 密钥 | 功能 | 是否接收奖励？ | -|-----|------|---------------| -| **服务密钥** | 标识您的贡献者身份并签署您的 CLI 命令。同时在链上命名您的奖励账户。 | 否 | -| **奖励管理密钥** | 签署对接收奖励的钱包列表的更改。 | 否 | -| **收款钱包** | 持有协议发送给您的 2Z。最多 8 个钱包。 | 是 | - -DoubleZero 基金会将您的奖励管理密钥注册到您的服务密钥上。只有 DZF 能执行此操作。此后，只有您的奖励管理密钥可以更改收款方列表，DZF 无法重定向您的奖励。 - -```mermaid -flowchart LR - DZF["DZF"] -->|"注册您的
奖励管理密钥"| ACC["您的链上
奖励账户"] - RM["奖励管理密钥
（由您持有，保持离线）"] -->|"设置收款方
和百分比"| ACC - ACC --> R1["收款钱包 1"] - ACC --> R2["收款钱包 2"] - PROTO["协议按每个
DZ 纪元支付"] -->|"2Z"| R1 - PROTO -->|"2Z"| R2 -``` - ---- - -## 前置条件 - -- 链上贡献者账户。使用 `doublezero contributor list` 检查。 -- 一个 Solana 钱包作为您的奖励管理器，持有约 0.01 SOL 用于支付交易费用。 -- 一个或多个用于接收 2Z 的钱包。 -- `doublezero-solana` CLI，如果您想使用命令行而非门户网站。使用 `sudo apt update && sudo apt install doublezero-solana` 安装。 - -!!! tip "为奖励管理密钥使用硬件钱包" - 奖励管理密钥控制着您的资金流向。请将其保存在硬件钱包上或以其他方式保持离线。它无需存放在服务器上，也不持有您的奖励。 - ---- - -## 步骤 1：创建您的奖励管理钱包 - -创建一个您控制且可以签名的 Solana 钱包。可以是硬件钱包、浏览器钱包或密钥对文件。 - -充入少量 SOL，约 0.01 SOL。这仅用于在您更改收款方列表时支付网络费用。 - -不要复用您的服务密钥。如果服务密钥存放在管理服务器上，任何能访问该服务器的人都可能重定向您的奖励。 - ---- - -## 步骤 2：将公钥发送给 DZF - -将您奖励管理钱包的**公钥**提供给 DZF。切勿分享私钥。 - -DZF 会将其注册到您的链上服务密钥，并在完成后确认。您无法自行完成此步骤。 - -!!! tip "与服务密钥一起发送" - 如果您正在按照 [设备配置指南](contribute-provisioning.md) 操作，请在 [步骤 2.4](contribute-provisioning.md#step-24-submit-keys-to-dzf) 中将此公钥与您的服务密钥和 GitHub 用户名一起发送。DZF 在不同的交易中注册这两个密钥，因此一起发送可以减少一次往返。 - -您可以检查是否已注册成功： - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - -u mainnet-beta -``` - -`manager` 列显示您的奖励管理密钥。如果为空，说明 DZF 尚未注册。 - ---- - -## 步骤 3：设置您的收款钱包 - -现在指定奖励的发送目标。您可以使用网页门户或 CLI。两者在链上写入的内容相同。 - -无论哪种方式都适用的规则： - -- 最多 8 个收款钱包。 -- 百分比必须为整数，且总和必须恰好为 100。 -- 收款方不能有 0% 的份额。请改为移除它。 - -!!! info "如果您与 DZF 的协议包含收入分成" - 部分贡献者的协议中约定与基金会分成奖励，例如 DZF 提供了硬件的情况。如果这适用于您，DZF 会提供需要在此处输入的地址和百分比。如果不确定，请咨询 DZF。 - -=== "网页门户" - - 1. 前往 [doublezero.xyz/rewards](https://doublezero.xyz/rewards)。旧地址 `rewards.doublezero.xyz` 会重定向到此处。 - 2. 使用右上角的钱包按钮连接您的奖励管理钱包。 - 3. 在下一页面的列表中选择您的服务密钥。 - 4. 输入每个收款钱包地址及其百分比。总计必须为 100%。 - 5. 点击 **Submit** 并在钱包中批准交易。 - -=== "CLI" - - 使用您的奖励管理密钥对作为 `-k` 运行此命令。为每个钱包重复 `--recipient`。 - - ```bash - doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --recipient :70 \ - --recipient :30 \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta - ``` - - | 标志 | 说明 | - |------|------| - | `--service-key` | 您的贡献者服务密钥。它在链上命名奖励账户。 | - | `--recipient` | 格式为 `PUBKEY:PERCENT` 的收款方。整数，1 到 100，总和为 100。最多 8 个。 | - | `-k` | 您的奖励管理密钥对。如果这不是已注册的奖励管理器，交易将失败。 | - | `-u` | `mainnet-beta`。 | - - 如果您想在不发送交易的情况下模拟，请先添加 `--dry-run`。 - ---- - -## 步骤 4：检查每个收款方是否可以持有 2Z - -协议通过普通代币转账发送 2Z。它**不会**为您创建代币账户。如果收款钱包没有 2Z 代币账户，该纪元的支付将失败。 - -主网上的 2Z 铸造地址为： - -``` -J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd -``` - -列出钱包已有的代币账户： - -```bash -spl-token accounts --owner -u m -``` - -如果 `J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd` 不在列表中，创建一次该账户： - -```bash -spl-token create-account J6pQQ3FAcJQeWPPGppWRb4nM8jU3wLyYbRrLh7feMfvd \ - --owner \ - --fee-payer /path/to/any-funded-keypair.json \ - -u m -``` - -任何有资金的钱包都可以为此付费。费用为少量 SOL，每个收款钱包只需执行一次。 - -!!! note "已持有 2Z 的钱包无需操作" - 如果该钱包曾经接收过 2Z，代币账户已存在，您可以跳过此步骤。 - ---- - -## 步骤 5：验证 - -检查链上当前记录的内容： - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key \ - --view recipients \ - -u mainnet-beta -``` - -示例输出： - -``` -| index | recipient | ata | proportion | -|-------|----------------------------------------------|----------------------------------------------|------------| -| 0 | Recipient1111111111111111111111111111111111 | Ata11111111111111111111111111111111111111111 | 70.00% | -| 1 | Recipient2222222222222222222222222222222222 | Ata22222222222222222222222222222222222222222 | 30.00% | -``` - -`ata` 列是每个收款方将收到支付的 2Z 代币账户。检查 `proportion` 列的总和是否为 100%。 - ---- - -## 奖励何时到账 - -- 奖励按 **DZ 纪元** 计算，即 DoubleZero 账本的纪元。一个 DZ 纪元大约运行两天。 -- 某个纪元的支付大约在该纪元结束后 10 个 DZ 纪元发生，即大约 20 天后。此延迟用于完成该纪元的核算。 -- 支付是自动的。您无需领取，也无需运行任何程序。 -- 一旦设置了收款方，支付将在几天内开始到账，随着下一批纪元被处理。在您设置收款方之前已经过去的纪元属于另一种情况，请参阅 [如果您设置较晚](#if-you-set-this-up-late)。 -- DZ 纪元和 Solana 纪元的长度不同。这种差异会随时间累积，因此偶尔某个 DZ 纪元会显示零奖励。这是正常现象。 - ---- - -## 在哪里查看您的奖励 - -**汇总视图。** [Economic Hub](https://doublezero.xyz/economic-hub) 在网络层面显示贡献者奖励。 - -**按纪元查看。** 查询协议在某个 DZ 纪元的支付情况： - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -输出列出每个贡献者及其份额、2Z 奖励金额以及是否已支付。在 `contributor` 列中找到您的贡献者代码。 - -要查看网络当前所在的 DZ 纪元，省略 `-e`： - -```bash -doublezero-solana revenue-distribution fetch distribution -u mainnet-beta -``` - -!!! note "近期纪元尚未最终确定" - 查询奖励尚未计算完成的纪元会返回 `Rewards calculation is not finalized yet`。请尝试查询更早的纪元。 - ---- - -## 如果您设置较晚 - -无论您在当时是否配置了收款方，您贡献的每个纪元的奖励都会被计算。这些奖励不会被销毁，也不会过期。它们保存在该纪元的分配账户中，直到有人提交支付。 - -问题在于事后没有人会自动为您提交。常规支付流程只处理近期纪元，因此在您的收款方列表为空时经过的纪元将保持未支付状态，直到手动提交。 - -要查找受影响的纪元，查找您的贡献者代码对应的行，其中 `distributed` 为 `no` 且奖励大于零： - -```bash -doublezero-solana revenue-distribution fetch distribution \ - -e --view rewards -u mainnet-beta -``` - -提交支付是无需许可的，因此一旦您配置了收款方，任何有资金的钱包都可以执行此操作，包括您自己的： - -```bash -doublezero-solana revenue-distribution relay distribute-rewards \ - -e -k /path/to/funded-keypair.json -u mainnet-beta -``` - -先添加 `--dry-run` 可以在不发送任何内容的情况下模拟。该命令会处理该纪元中的每个贡献者并跳过已支付的，因此运行是安全的。 - -如果您不想自己操作，可以请 DZF 为您提交这些纪元。 - ---- - -## 稍后更改收款方 - -随时重复 [步骤 3](#step-3-set-your-recipient-wallets)。新列表会完全替换旧列表，因此请包含您仍然需要的所有收款方，而不仅仅是新增的。百分比必须再次总和为 100。 - -对于您添加的任何钱包，请记得执行 [步骤 4](#step-4-check-each-recipient-can-hold-2z)。 - ---- - -## 锁定奖励管理密钥 - -默认情况下，DZF 可以更改您的奖励管理密钥，这在您丢失访问权限时很有用。如果您希望排除这种可能性，可以阻止它： - -```bash -doublezero-solana revenue-distribution configure-contributor-rewards \ - --service-key \ - --block-protocol-management \ - -k /path/to/rewards-manager-keypair.json \ - -u mainnet-beta -``` - -!!! danger "不要锁定可能丢失的密钥" - 一旦管理被阻止，任何人都无法替换您的奖励管理密钥，包括 DZF。如果您随后丢失该密钥，您将无法再更改奖励的发送目标。仅在密钥已备份且安全的情况下才执行锁定。 - -要重新允许，请使用 `--allow-protocol-management` 运行相同的命令。 - ---- - -## 故障排除 - -**`manager` 列为空。** -DZF 尚未注册您的奖励管理密钥。将公钥发送给他们并请求确认。 - -**`Invalid rewards manager`。** -您用于签名的密钥对不是已注册的奖励管理器。检查您是否向 `-k` 传递了正确的文件，或在门户中使用了正确的钱包。 - -**`Invalid recipients`。** -您的百分比总和不恰好为 100，您列出了超过 8 个收款方，或者其中一个的份额为 0%。 - -**奖励显示已赚取但未收到。** -两个常见原因。要么未配置收款方，因此没有发送目标；要么收款钱包没有 2Z 代币账户。请按照 [步骤 4](#step-4-check-each-recipient-can-hold-2z) 和 [步骤 5](#step-5-verify) 进行排查。修复后，未来的纪元会自动支付。已经过去的纪元需要 [手动支付](#if-you-set-this-up-late)。 - -**您近期纪元的奖励为 0。** -奖励有大约 10 个 DZ 纪元的延迟。请检查至少那么久之前的纪元。偶尔出现零奖励纪元也是正常的，请参阅 [奖励何时到账](#when-rewards-arrive)。 - ---- - -## 后续步骤 - -返回 [入门检查清单](contribute-overview.md#onboarding-checklist)，或继续前往 [运维](contribute-operations.md)。 \ No newline at end of file diff --git a/docs/glossary.md b/docs/glossary.md index 3dac5d8..2aea561 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -163,7 +163,7 @@ A cryptographic keypair used to authenticate CLI operations. This is your contri A cryptographic keypair used by the [Telemetry Agent](#telemetry-agent) to sign metric submissions to the blockchain. Separate from the service key for security isolation. Stored at `~/.config/doublezero/metrics-publisher.json`. ### Rewards Manager Key -A cryptographic keypair that controls where a contributor's rewards are paid. It signs changes to the list of recipient wallets but never holds rewards itself. Registered against the contributor's [Service Key](#service-key) by [DZF](#dzf-doublezero-foundation). See [Rewards Management](contribute-rewards.md). +A cryptographic keypair that controls where a contributor's rewards are paid. It signs changes to the list of recipient wallets but never holds rewards itself. Kept separate from the [Service Key](#service-key). See [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management) in the contributors repository. --- diff --git a/mkdocs.yml b/mkdocs.yml index 6b61193..1f5b4da 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -101,7 +101,6 @@ nav: - Overview: contribute-overview.md - Requirements & Architecture: contribute.md - Device Provisioning: contribute-provisioning.md - - Rewards Management: contribute-rewards.md - Operations: contribute-operations.md - OPS Management: contribute-ops-management.md - Geolocation: contribute-geolocation.md From d8d108e7b2e9314de16ad63141977a19bdca2fbb Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Thu, 10 Sep 2026 10:26:17 +0000 Subject: [PATCH 4/4] chore: auto-translate docs --- docs/contribute-overview.es.md | 101 ++++---- docs/contribute-overview.fr.md | 133 +++++----- docs/contribute-overview.it.md | 135 +++++----- docs/contribute-overview.ja.md | 207 ++++++++------- docs/contribute-overview.ko.md | 137 +++++----- docs/contribute-overview.pt.md | 101 ++++---- docs/contribute-overview.zh.md | 107 ++++---- docs/contribute-provisioning.es.md | 317 ++++++++++++----------- docs/contribute-provisioning.fr.md | 398 +++++++++++++++-------------- docs/contribute-provisioning.it.md | 271 ++++++++++---------- docs/contribute-provisioning.ja.md | 265 +++++++++---------- docs/contribute-provisioning.ko.md | 265 ++++++++++--------- docs/contribute-provisioning.pt.md | 250 +++++++++--------- docs/contribute-provisioning.zh.md | 262 ++++++++++--------- docs/contribute.es.md | 118 ++++----- docs/contribute.fr.md | 166 ++++++------ docs/contribute.it.md | 132 +++++----- docs/contribute.ja.md | 142 +++++----- docs/contribute.ko.md | 112 ++++---- docs/contribute.pt.md | 114 ++++----- docs/contribute.zh.md | 134 +++++----- docs/glossary.es.md | 62 ++--- docs/glossary.fr.md | 92 +++---- docs/glossary.it.md | 64 ++--- docs/glossary.ja.md | 70 ++--- docs/glossary.ko.md | 74 +++--- docs/glossary.pt.md | 80 +++--- docs/glossary.zh.md | 118 ++++----- 28 files changed, 2289 insertions(+), 2138 deletions(-) diff --git a/docs/contribute-overview.es.md b/docs/contribute-overview.es.md index a9bd710..5acd774 100644 --- a/docs/contribute-overview.es.md +++ b/docs/contribute-overview.es.md @@ -16,31 +16,47 @@ Bienvenido a la documentación para contribuidores de DoubleZero. Esta sección ## Lista de Verificación de Incorporación -Use esta lista de verificación para seguir su progreso. **Todos los elementos deben completarse antes de que su contribución esté técnicamente operativa.** +Utilice esta lista de verificación para seguir su progreso. **Todos los elementos deben completarse antes de que su contribución esté técnicamente operativa.** ### Fase 1: Prerrequisitos - [ ] CLI de DoubleZero instalado en un servidor de gestión -- [ ] Hardware adquirido y cumple con los [requisitos](contribute.md#hardware-requirements) -- [ ] Espacio en rack y alimentación eléctrica disponibles en el centro de datos (consulte [Rack y Alimentación](contribute.md#rack-power-requirements)) +- [ ] Hardware adquirido y que cumple con los [requisitos](contribute.md#hardware-requirements) +- [ ] Espacio en rack del centro de datos y energía disponibles (ver [Rack y Energía](contribute.md#rack-power-requirements)) - [ ] DZD instalado físicamente con conectividad de gestión -- [ ] Bloque de IPv4 público asignado para el protocolo DZ (**consulte [Reglas de Prefijos DZ](#reglas-de-prefijos-dz)**) +- [ ] Bloque público de IPv4 asignado para el protocolo DZ (**ver [Reglas de Prefijos DZ](#reglas-de-prefijos-dz)**) ### Fase 2: Configuración de Cuenta + +Esta fase alterna entre el contribuidor y DZF. Cada elemento de **DZF** debe confirmarse antes de que pueda comenzar el siguiente grupo. + +**Contribuidor** + +- [ ] Nombre de usuario de GitHub enviado a DZF + +**DZF** + +- [ ] Acceso concedido al repositorio [malbeclabs/contributors](https://github.com/malbeclabs/contributors) + +**Contribuidor** + - [ ] Par de claves de servicio generado (`doublezero keygen`) - [ ] Par de claves del publicador de métricas generado -- [ ] Billetera del gestor de recompensas creada y financiada con ~0.01 SOL -- [ ] Clave de servicio, clave del gestor de recompensas y nombre de usuario de GitHub enviados a DZF (solo claves públicas) -- [ ] Cuenta de contribuidor creada onchain (verificar con `doublezero contributor list`) -- [ ] Clave del gestor de recompensas registrada onchain por DZF -- [ ] Acceso otorgado al repositorio [malbeclabs/contributors](https://github.com/malbeclabs/contributors) -- [ ] Billeteras receptoras y porcentajes configurados (**consulte [Gestión de Recompensas](contribute-rewards.md)**) -- [ ] Cada billetera receptora tiene una cuenta de token 2Z - -### Fase 3: Aprovisionamiento del Dispositivo +- [ ] **Clave pública** de la clave de servicio enviada a DZF + +**DZF** + +- [ ] Cuenta de contribuidor creada onchain + +**Contribuidor** + +- [ ] Cuenta de contribuidor verificada (`doublezero contributor list`) +- [ ] Gestión de recompensas configurada (no bloquea la puesta en producción, **ver [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management) en el repositorio de contribuidores**) + +### Fase 3: Aprovisionamiento de Dispositivos - [ ] Configuración base del dispositivo aplicada (desde el repositorio de contribuidores) - [ ] Dispositivo creado onchain (`doublezero device create`) - [ ] Interfaces del dispositivo registradas -- [ ] Interfaces loopback creadas (Loopback255 vpnv4, Loopback256 ipv4) +- [ ] Interfaces de loopback creadas (Loopback255 vpnv4, Loopback256 ipv4) - [ ] Interfaces CYOA/DIA configuradas (si es dispositivo edge/híbrido) ### Fase 4: Establecimiento de Enlaces e Instalación de Agentes @@ -54,8 +70,8 @@ Use esta lista de verificación para seguir su progreso. **Todos los elementos d - [ ] Envíos de telemetría visibles en el ledger ### Fase 5: Período de Prueba de Enlaces -- [ ] Todos los enlaces drenados para un período de prueba de 24 horas -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) muestra cero pérdida y cero errores durante 24h +- [ ] Todos los enlaces drenados durante un período de prueba de 24 horas +- [ ] El [panel de estado de enlaces](https://data.doublezero.xyz/status/links) muestra cero pérdidas y cero errores durante 24h - [ ] Enlaces restaurados después de una prueba limpia ### Fase 6: Verificación y Activación @@ -63,38 +79,38 @@ Use esta lista de verificación para seguir su progreso. **Todos los elementos d - [ ] `doublezero link list` muestra sus enlaces - [ ] Los registros del Config Agent muestran obtenciones de configuración exitosas - [ ] Los registros del Telemetry Agent muestran envíos de métricas exitosos -- [ ] **Coordinar con DZ/Malbec Labs** para ejecutar prueba de conectividad (conectar, recibir rutas, enrutar por DZ) -- [ ] Después de pasar la prueba, establecer `max_users` a 96 mediante `doublezero device update` +- [ ] **Coordinar con DZ/Malbec Labs** para ejecutar la prueba de conectividad (conectar, recibir rutas, enrutar sobre DZ) +- [ ] Después de que la prueba pase, establecer `max_users` a 96 mediante `doublezero device update` --- ## Obtener Ayuda -Como parte de la incorporación, DZF le añadirá a los canales de Slack para contribuidores: +Como parte de la incorporación, DZF lo añadirá a los canales de Slack para contribuidores: | Canal | Propósito | |-------|-----------| | **#dz-contributor-announcements** | Comunicaciones oficiales de DZF y Malbec Labs — actualizaciones de CLI/agentes, cambios incompatibles, anuncios de seguridad. Monitoree para actualizaciones críticas; haga preguntas en hilos. | -| **#dz-contributor-incidents** | Eventos no planificados con impacto en el servicio. Los incidentes se publican automáticamente a través de la API/formulario web con severidad y dispositivos/enlaces afectados. La discusión y resolución de problemas ocurre en hilos. | -| **#dz-contributor-maintenance** | Actividades de mantenimiento planificadas (actualizaciones, reparaciones). Programadas a través de la API/formulario web con horarios de inicio/fin planificados. Discusión en hilos. | +| **#dz-contributor-incidents** | Eventos no planificados que impactan el servicio. Los incidentes se publican automáticamente vía la API/formulario web con severidad y dispositivos/enlaces afectados. La discusión y resolución de problemas ocurre en hilos. | +| **#dz-contributor-maintenance** | Actividades de mantenimiento planificado (actualizaciones, reparaciones). Programadas vía la API/formulario web con tiempos de inicio/fin planificados. Discusión en hilos. | | **#dz-contributor-ops** | Discusión abierta para todos los contribuidores — preguntas operativas, ayuda con CLI, compartir runbooks y playbooks. | -También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo para su organización. +También obtendrá un **canal privado de DZ/Malbec Labs** para soporte directo para su organización. --- ## Reglas de Prefijos DZ !!! warning "Crítico: Uso del Pool de Prefijos DZ" - El pool de prefijos DZ que usted proporciona es **gestionado por el protocolo DoubleZero para la asignación de IP**. + El pool de prefijos DZ que usted proporciona es **gestionado por el protocolo DoubleZero para la asignación de IPs**. - **Cómo se utilizan los prefijos DZ:** + **Cómo se usan los prefijos DZ:** - **Primera IP**: Reservada para su dispositivo (asignada a la interfaz Loopback100) - **IPs restantes**: Asignadas a tipos específicos de usuarios que se conectan a su DZD: - Usuarios `IBRLWithAllocatedIP` - Usuarios `EdgeFiltering` - - Publicadores multicast + - Publicadores de multicast - **Usuarios IBRL**: NO consumen de este pool (usan su propia IP pública) **NO PUEDE usar estas direcciones para:** @@ -107,31 +123,31 @@ También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo p **Requisitos:** - Deben ser direcciones IPv4 **enrutables globalmente (públicas)** - - Los rangos de IP privados (10.x, 172.16-31.x, 192.168.x) son rechazados por el contrato inteligente + - Los rangos de IP privadas (10.x, 172.16-31.x, 192.168.x) son rechazados por el contrato inteligente - **Tamaño mínimo: /29** (8 direcciones), se prefieren prefijos más grandes (ej., /28, /27) - El bloque completo debe estar disponible - no pre-asigne ninguna dirección - Si necesita direcciones para su propio equipamiento (IPs de interfaz DIA, gestión, etc.), use un **pool de direcciones separado**. + Si necesita direcciones para su propio equipamiento (IPs de interfaces DIA, gestión, etc.), use un **pool de direcciones separado**. --- ## Referencia Rápida: Términos Clave -¿Nuevo en DoubleZero? Aquí están los términos esenciales (consulte el [Glosario completo](glossary.md)): +¿Nuevo en DoubleZero? Estos son los términos esenciales (ver [Glosario completo](glossary.md)): | Término | Definición | |---------|------------| | **DZD** | DoubleZero Device - su switch Arista físico ejecutando agentes DZ | -| **DZX** | DoubleZero Exchange - punto de interconexión metropolitana donde los contribuidores establecen peering | -| **CYOA** | Choose Your Own Adventure - método de conectividad de usuario (GREOverDIA, GREOverFabric, etc.) | -| **DIA** | Direct Internet Access - conectividad a internet requerida por todos los DZDs para el controlador y telemetría, comúnmente usado como tipo CYOA para conectividad de usuarios en dispositivos edge/híbridos | +| **DZX** | DoubleZero Exchange - punto de interconexión metropolitano donde los contribuidores establecen peering | +| **CYOA** | Choose Your Own Adventure - método de conectividad del usuario (GREOverDIA, GREOverFabric, etc.) | +| **DIA** | Direct Internet Access - conectividad a internet requerida por todos los DZDs para el controlador y la telemetría, comúnmente utilizada como tipo CYOA para la conectividad de usuarios en dispositivos edge/híbridos | | **WAN Link** | Enlace entre sus propios DZDs (mismo contribuidor) | | **DZX Link** | Enlace al DZD de otro contribuidor (requiere aceptación mutua) | -| **Config Agent** | Consulta el controlador, aplica configuración a su DZD | +| **Config Agent** | Consulta al controlador y aplica la configuración a su DZD | | **Telemetry Agent** | Recopila métricas de latencia/pérdida TWAMP, las envía al ledger onchain | | **Service Key** | Su clave de identidad de contribuidor para operaciones con CLI | | **Metrics Publisher Key** | Clave para firmar envíos de telemetría onchain | -| **Rewards Manager Key** | Clave que controla qué billeteras reciben sus recompensas | +| **Rewards Manager Key** | Clave que controla qué wallets reciben sus recompensas (ver el repositorio de contribuidores) | --- @@ -142,17 +158,16 @@ También recibirá un **canal privado de DZ/Malbec Labs** para soporte directo p | Guía | Descripción | |------|-------------| | [Requisitos y Arquitectura](contribute.md) | Especificaciones de hardware, arquitectura de red, opciones de ancho de banda | -| [Aprovisionamiento de Dispositivos](contribute-provisioning.md) | Paso a paso: claves → acceso al repositorio → dispositivo → enlaces → agentes | -| [Gestión de Recompensas](contribute-rewards.md) | Configurar las billeteras que reciben sus recompensas 2Z | -| [Operaciones](contribute-operations.md) | Actualizaciones de agentes, gestión de enlaces, monitoreo | +| [Aprovisionamiento de Dispositivos](contribute-provisioning.md) | Paso a paso: acceso al repositorio → claves → dispositivo → enlaces → agentes | +| [Operaciones](contribute-operations.md) | Actualización de agentes, gestión de enlaces, monitoreo | | [Despliegue de Geoprobe](contribute-geolocation.md) | Despliegue y configuración de agentes geoProbe para geolocalización | | [Glosario](glossary.md) | Toda la terminología de DoubleZero definida | --- -## Conceptos Básicos de Red para No Ingenieros de Redes +## Conceptos Básicos de Redes para No Ingenieros de Redes -Si no tiene experiencia en ingeniería de redes, aquí hay una introducción a los conceptos utilizados en esta documentación: +Si no proviene de un contexto de ingeniería de redes, aquí tiene una introducción a los conceptos utilizados en esta documentación: ### Direccionamiento IP @@ -162,14 +177,14 @@ Si no tiene experiencia en ingeniería de redes, aquí hay una introducción a l ### Capas de Red -- **Capa 1 (Física)**: Cables, óptica, longitudes de onda +- **Capa 1 (Física)**: Cables, ópticas, longitudes de onda - **Capa 2 (Enlace de Datos)**: Switches, VLANs, direcciones MAC - **Capa 3 (Red)**: Routers, direcciones IP, protocolos de enrutamiento ### Términos Comunes -- **MTU**: Maximum Transmission Unit - tamaño máximo de paquete (típicamente 9000 bytes para enlaces WAN) -- **VLAN**: Virtual LAN - separa lógicamente el tráfico en infraestructura compartida +- **MTU**: Unidad Máxima de Transmisión - tamaño máximo de paquete (típicamente 9000 bytes para enlaces WAN) +- **VLAN**: LAN Virtual - separa lógicamente el tráfico en infraestructura compartida - **VRF**: Virtual Routing and Forwarding - aísla tablas de enrutamiento en el mismo dispositivo - **BGP**: Border Gateway Protocol - intercambio de rutas entre redes - **GRE**: Generic Routing Encapsulation - protocolo de tunelización para redes overlay @@ -177,9 +192,9 @@ Si no tiene experiencia en ingeniería de redes, aquí hay una introducción a l ### Específico de DoubleZero -- **Onchain**: En DoubleZero, los registros de dispositivos, configuraciones de enlaces y telemetría se registran en el ledger de DoubleZero — haciendo que el estado de la red sea transparente y verificable por todos los participantes +- **Onchain**: En DoubleZero, los registros de dispositivos, las configuraciones de enlaces y la telemetría se registran en el ledger de DoubleZero — haciendo que el estado de la red sea transparente y verificable por todos los participantes - **Controlador**: Servicio que deriva la configuración del DZD a partir del estado onchain en el ledger de DoubleZero --- -¿Listo para comenzar? Empiece con [Requisitos y Arquitectura](contribute.md). \ No newline at end of file +¿Listo para comenzar? Comience con [Requisitos y Arquitectura](contribute.md). \ No newline at end of file diff --git a/docs/contribute-overview.fr.md b/docs/contribute-overview.fr.md index 70ccbba..d819fcb 100644 --- a/docs/contribute-overview.fr.md +++ b/docs/contribute-overview.fr.md @@ -1,40 +1,56 @@ --- -description: Aperçu et liste de vérification d'intégration pour devenir contributeur au réseau DoubleZero. +description: Vue d'ensemble et checklist d'intégration pour devenir contributeur au réseau DoubleZero. --- -# Documentation pour les contributeurs +# Documentation Contributeur !!! info "Terminologie" - Vous découvrez DoubleZero ? Consultez le [Glossaire](glossary.md) pour les définitions des termes clés comme [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) et [CYOA](glossary.md#cyoa-choose-your-own-adventure). + Nouveau sur DoubleZero ? Consultez le [Glossaire](glossary.md) pour les définitions des termes clés comme [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) et [CYOA](glossary.md#cyoa-choose-your-own-adventure). -Bienvenue dans la documentation pour les contributeurs DoubleZero. Cette section couvre tout ce dont vous avez besoin pour devenir contributeur au réseau. +Bienvenue dans la documentation contributeur DoubleZero. Cette section couvre tout ce dont vous avez besoin pour devenir contributeur au réseau. -!!! tip "Intéressé à devenir contributeur au réseau ?" - Consultez la page [Exigences et architecture](contribute.md) pour comprendre le matériel, la bande passante et la connectivité nécessaires pour contribuer au réseau DoubleZero. +!!! tip "Intéressé pour devenir contributeur au réseau ?" + Consultez la page [Exigences & Architecture](contribute.md) pour comprendre le matériel, la bande passante et la connectivité nécessaires pour contribuer au réseau DoubleZero. --- -## Liste de vérification d'intégration +## Checklist d'intégration -Utilisez cette liste de vérification pour suivre votre progression. **Tous les éléments doivent être complétés avant que votre contribution soit techniquement opérationnelle.** +Utilisez cette checklist pour suivre votre progression. **Tous les éléments doivent être complétés avant que votre contribution soit techniquement opérationnelle.** ### Phase 1 : Prérequis - [ ] CLI DoubleZero installé sur un serveur de gestion -- [ ] Matériel procuré et conforme aux [exigences](contribute.md#hardware-requirements) -- [ ] Espace rack et alimentation disponibles dans le centre de données (voir [Rack et alimentation](contribute.md#rack-power-requirements)) +- [ ] Matériel acquis et conforme aux [exigences](contribute.md#hardware-requirements) +- [ ] Espace rack et alimentation disponibles dans le centre de données (voir [Rack & Alimentation](contribute.md#rack-power-requirements)) - [ ] DZD physiquement installé avec connectivité de gestion -- [ ] Bloc IPv4 public alloué pour le protocole DZ (**voir [Règles de préfixe DZ](#regles-de-prefixe-dz)**) +- [ ] Bloc IPv4 public alloué pour le protocole DZ (**voir [Règles des préfixes DZ](#dz-prefix-rules)**) ### Phase 2 : Configuration du compte + +Cette phase alterne entre le contributeur et DZF. Chaque élément **DZF** doit être confirmé avant que le groupe suivant puisse commencer. + +**Contributeur** + +- [ ] Nom d'utilisateur GitHub envoyé à DZF + +**DZF** + +- [ ] Accès accordé au dépôt [malbeclabs/contributors](https://github.com/malbeclabs/contributors) + +**Contributeur** + - [ ] Paire de clés de service générée (`doublezero keygen`) - [ ] Paire de clés de publication de métriques générée -- [ ] Portefeuille du gestionnaire de récompenses créé et alimenté avec ~0.01 SOL -- [ ] Clé de service, clé du gestionnaire de récompenses et nom d'utilisateur GitHub soumis à la DZF (clés publiques uniquement) -- [ ] Compte contributeur créé onchain (vérifier avec `doublezero contributor list`) -- [ ] Clé du gestionnaire de récompenses enregistrée onchain par la DZF -- [ ] Accès accordé au dépôt [malbeclabs/contributors](https://github.com/malbeclabs/contributors) -- [ ] Portefeuilles destinataires et pourcentages configurés (**voir [Gestion des récompenses](contribute-rewards.md)**) -- [ ] Chaque portefeuille destinataire dispose d'un compte de jetons 2Z +- [ ] **Clé publique** de la clé de service envoyée à DZF + +**DZF** + +- [ ] Compte contributeur créé onchain + +**Contributeur** + +- [ ] Compte contributeur vérifié (`doublezero contributor list`) +- [ ] Gestion des récompenses configurée (ne bloque pas la mise en production, **voir [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management) dans le dépôt contributors**) ### Phase 3 : Provisionnement de l'appareil - [ ] Configuration de base de l'appareil appliquée (depuis le dépôt contributors) @@ -43,47 +59,47 @@ Utilisez cette liste de vérification pour suivre votre progression. **Tous les - [ ] Interfaces loopback créées (Loopback255 vpnv4, Loopback256 ipv4) - [ ] Interfaces CYOA/DIA configurées (si appareil edge/hybride) -### Phase 4 : Établissement des liens et installation de l'agent -- [ ] Liens WAN créés (le cas échéant) +### Phase 4 : Établissement des liens & Installation de l'agent +- [ ] Liens WAN créés (si applicable) - [ ] Lien DZX créé (statut : `requested`) - [ ] Lien DZX accepté par le contributeur pair -- [ ] Config Agent installé et en fonctionnement +- [ ] Config Agent installé et en cours d'exécution - [ ] Config Agent recevant la configuration du contrôleur -- [ ] Telemetry Agent installé et en fonctionnement -- [ ] Éditeur de métriques enregistré onchain +- [ ] Telemetry Agent installé et en cours d'exécution +- [ ] Publication de métriques enregistrée onchain - [ ] Soumissions de télémétrie visibles sur le registre ### Phase 5 : Rodage des liens -- [ ] Tous les liens vidés pour une période de rodage de 24 heures -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) affiche zéro perte et zéro erreur pendant 24h -- [ ] Liens réactivés après un rodage propre +- [ ] Tous les liens drainés pour une période de rodage de 24 heures +- [ ] Le [tableau de bord de statut des liens](https://data.doublezero.xyz/status/links) affiche zéro perte et zéro erreur pendant 24h +- [ ] Liens dédrainés après un rodage propre -### Phase 6 : Vérification et activation +### Phase 6 : Vérification & Activation - [ ] `doublezero device list` affiche votre appareil (avec `max_users = 0`) - [ ] `doublezero link list` affiche vos liens -- [ ] Les journaux du Config Agent montrent des extractions de configuration réussies -- [ ] Les journaux du Telemetry Agent montrent des soumissions de métriques réussies -- [ ] **Coordonner avec DZ/Malbec Labs** pour exécuter un test de connectivité (connexion, réception de routes, routage via DZ) +- [ ] Les logs du Config Agent montrent des récupérations de configuration réussies +- [ ] Les logs du Telemetry Agent montrent des soumissions de métriques réussies +- [ ] **Coordonner avec DZ/Malbec Labs** pour exécuter un test de connectivité (connexion, réception des routes, routage via DZ) - [ ] Après la réussite du test, définir `max_users` à 96 via `doublezero device update` --- ## Obtenir de l'aide -Dans le cadre de l'intégration, la DZF vous ajoutera aux canaux Slack des contributeurs : +Dans le cadre de l'intégration, DZF vous ajoutera aux canaux Slack contributeurs : | Canal | Objectif | |-------|----------| -| **#dz-contributor-announcements** | Communications officielles de la DZF et Malbec Labs — mises à jour CLI/agents, changements majeurs, annonces de sécurité. Surveillez les mises à jour critiques ; posez vos questions dans les fils de discussion. | -| **#dz-contributor-incidents** | Événements non planifiés impactant le service. Les incidents sont publiés automatiquement via l'API/formulaire web avec la sévérité et les appareils/liens affectés. Les discussions et le dépannage se font dans les fils. | -| **#dz-contributor-maintenance** | Activités de maintenance planifiées (mises à jour, réparations). Programmées via l'API/formulaire web avec les heures de début/fin prévues. Discussions dans les fils. | +| **#dz-contributor-announcements** | Communications officielles de DZF et Malbec Labs — mises à jour CLI/agent, changements incompatibles, annonces de sécurité. Surveillez les mises à jour critiques ; posez vos questions dans les fils de discussion. | +| **#dz-contributor-incidents** | Événements imprévus impactant le service. Les incidents sont publiés automatiquement via l'API/formulaire web avec la sévérité et les appareils/liens affectés. La discussion et le dépannage se font dans les fils de discussion. | +| **#dz-contributor-maintenance** | Activités de maintenance planifiées (mises à niveau, réparations). Planifiées via l'API/formulaire web avec les heures de début/fin prévues. Discussion dans les fils de discussion. | | **#dz-contributor-ops** | Discussion ouverte pour tous les contributeurs — questions opérationnelles, aide CLI, partage de runbooks et playbooks. | -Vous obtiendrez également un **canal privé DZ/Malbec Labs** pour un support direct pour votre organisation. +Vous recevrez également un **canal privé DZ/Malbec Labs** pour le support direct de votre organisation. --- -## Règles de préfixe DZ +## Règles des préfixes DZ !!! warning "Critique : Utilisation du pool de préfixes DZ" Le pool de préfixes DZ que vous fournissez est **géré par le protocole DoubleZero pour l'allocation d'adresses IP**. @@ -91,7 +107,7 @@ Vous obtiendrez également un **canal privé DZ/Malbec Labs** pour un support di **Comment les préfixes DZ sont utilisés :** - **Première IP** : Réservée pour votre appareil (assignée à l'interface Loopback100) - - **IP restantes** : Allouées à des types d'utilisateurs spécifiques se connectant à votre DZD : + - **IPs restantes** : Allouées à des types d'utilisateurs spécifiques se connectant à votre DZD : - Utilisateurs `IBRLWithAllocatedIP` - Utilisateurs `EdgeFiltering` - Éditeurs multicast @@ -100,38 +116,38 @@ Vous obtiendrez également un **canal privé DZ/Malbec Labs** pour un support di **Vous NE POUVEZ PAS utiliser ces adresses pour :** - Votre propre équipement réseau - - Les liens point à point sur les interfaces DIA + - Les liens point-à-point sur les interfaces DIA - Les interfaces de gestion - Toute infrastructure en dehors du protocole DZ **Exigences :** - Doivent être des adresses IPv4 **routables globalement (publiques)** - - Les plages d'IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le contrat intelligent - - **Taille minimale : /29** (8 adresses), les préfixes plus grands sont préférés (par ex., /28, /27) - - L'ensemble du bloc doit être disponible — ne pré-allouez aucune adresse + - Les plages d'IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le smart contract + - **Taille minimale : /29** (8 adresses), les préfixes plus grands sont préférés (ex. /28, /27) + - Le bloc entier doit être disponible — ne pré-allouez aucune adresse - Si vous avez besoin d'adresses pour votre propre équipement (IP d'interface DIA, gestion, etc.), utilisez un **pool d'adresses séparé**. + Si vous avez besoin d'adresses pour votre propre équipement (IPs d'interface DIA, gestion, etc.), utilisez un **pool d'adresses séparé**. --- ## Référence rapide : Termes clés -Vous découvrez DoubleZero ? Voici les termes essentiels (voir le [Glossaire complet](glossary.md)) : +Nouveau sur DoubleZero ? Voici les termes essentiels (voir le [Glossaire complet](glossary.md)) : | Terme | Définition | |-------|------------| -| **DZD** | DoubleZero Device - votre commutateur physique Arista exécutant les agents DZ | +| **DZD** | DoubleZero Device - votre switch physique Arista exécutant les agents DZ | | **DZX** | DoubleZero Exchange - point d'interconnexion métropolitain où les contributeurs s'appairent | | **CYOA** | Choose Your Own Adventure - méthode de connectivité utilisateur (GREOverDIA, GREOverFabric, etc.) | -| **DIA** | Direct Internet Access - connectivité internet requise par tous les DZD pour le contrôleur et la télémétrie, couramment utilisé comme type CYOA pour la connectivité utilisateur sur les appareils edge/hybrides | -| **WAN Link** | Lien entre vos propres DZD (même contributeur) | +| **DIA** | Direct Internet Access - connectivité internet requise par tous les DZDs pour le contrôleur et la télémétrie, couramment utilisé comme type CYOA pour la connectivité utilisateur sur les appareils edge/hybrides | +| **WAN Link** | Lien entre vos propres DZDs (même contributeur) | | **DZX Link** | Lien vers le DZD d'un autre contributeur (nécessite une acceptation mutuelle) | | **Config Agent** | Interroge le contrôleur, applique la configuration à votre DZD | | **Telemetry Agent** | Collecte les métriques de latence/perte TWAMP, les soumet au registre onchain | -| **Service Key** | Votre clé d'identité de contributeur pour les opérations CLI | +| **Service Key** | Votre clé d'identité contributeur pour les opérations CLI | | **Metrics Publisher Key** | Clé pour signer les soumissions de télémétrie onchain | -| **Rewards Manager Key** | Clé qui contrôle quels portefeuilles reçoivent vos récompenses | +| **Rewards Manager Key** | Clé qui contrôle quels portefeuilles reçoivent vos récompenses (voir le dépôt contributors) | --- @@ -141,45 +157,44 @@ Vous découvrez DoubleZero ? Voici les termes essentiels (voir le [Glossaire com | Guide | Description | |-------|-------------| -| [Exigences et architecture](contribute.md) | Spécifications matérielles, architecture réseau, options de bande passante | -| [Provisionnement de l'appareil](contribute-provisioning.md) | Étape par étape : clés → accès au dépôt → appareil → liens → agents | -| [Gestion des récompenses](contribute-rewards.md) | Configuration des portefeuilles qui reçoivent vos récompenses 2Z | +| [Exigences & Architecture](contribute.md) | Spécifications matérielles, architecture réseau, options de bande passante | +| [Provisionnement de l'appareil](contribute-provisioning.md) | Étape par étape : accès au dépôt → clés → appareil → liens → agents | | [Opérations](contribute-operations.md) | Mises à jour des agents, gestion des liens, surveillance | | [Déploiement de Geoprobe](contribute-geolocation.md) | Déploiement et configuration des agents geoProbe pour la géolocalisation | | [Glossaire](glossary.md) | Toute la terminologie DoubleZero définie | --- -## Bases du réseau pour les non-ingénieurs réseau +## Notions de base réseau pour les non-ingénieurs réseau Si vous ne venez pas d'un milieu d'ingénierie réseau, voici une introduction aux concepts utilisés dans cette documentation : ### Adressage IP -- **Adresse IPv4** : Un identifiant unique pour un appareil sur un réseau (par ex., `192.168.1.1`) +- **Adresse IPv4** : Un identifiant unique pour un appareil sur un réseau (ex. `192.168.1.1`) - **Notation CIDR** (`/29`, `/24`) : Indique la taille du sous-réseau. `/29` = 8 adresses, `/24` = 256 adresses - **IP publique** : Routable sur internet ; **IP privée** : Réseaux internes uniquement (10.x, 172.16-31.x, 192.168.x) ### Couches réseau - **Couche 1 (Physique)** : Câbles, optiques, longueurs d'onde -- **Couche 2 (Liaison de données)** : Commutateurs, VLAN, adresses MAC +- **Couche 2 (Liaison de données)** : Switches, VLANs, adresses MAC - **Couche 3 (Réseau)** : Routeurs, adresses IP, protocoles de routage ### Termes courants -- **MTU** : Maximum Transmission Unit - taille maximale de paquet (généralement 9000 octets pour les liens WAN) +- **MTU** : Maximum Transmission Unit - taille maximale de paquet (typiquement 9000 octets pour les liens WAN) - **VLAN** : Virtual LAN - sépare logiquement le trafic sur une infrastructure partagée -- **VRF** : Virtual Routing and Forwarding - isole les tables de routage sur le même appareil +- **VRF** : Virtual Routing and Forwarding - isole les tables de routage sur un même appareil - **BGP** : Border Gateway Protocol - échange de routes inter-réseaux -- **GRE** : Generic Routing Encapsulation - protocole de tunnellisation pour les réseaux overlay +- **GRE** : Generic Routing Encapsulation - protocole de tunneling pour les réseaux overlay - **TWAMP** : Two-Way Active Measurement Protocol - mesure la latence/perte entre les appareils ### Spécifique à DoubleZero - **Onchain** : Dans DoubleZero, les enregistrements d'appareils, les configurations de liens et la télémétrie sont enregistrés sur le registre DoubleZero — rendant l'état du réseau transparent et vérifiable par tous les participants -- **Contrôleur** : Service qui dérive la configuration du DZD à partir de l'état onchain sur le registre DoubleZero +- **Contrôleur** : Service qui dérive la configuration DZD à partir de l'état onchain sur le registre DoubleZero --- -Prêt à commencer ? Démarrez avec [Exigences et architecture](contribute.md). \ No newline at end of file +Prêt à commencer ? Débutez avec [Exigences & Architecture](contribute.md). \ No newline at end of file diff --git a/docs/contribute-overview.it.md b/docs/contribute-overview.it.md index afc5673..ded3b96 100644 --- a/docs/contribute-overview.it.md +++ b/docs/contribute-overview.it.md @@ -1,103 +1,119 @@ --- -description: Panoramica e checklist di onboarding per diventare un contributor della rete DoubleZero. +description: Panoramica e checklist di onboarding per diventare un contributore della rete DoubleZero. --- -# Documentazione per i Contributor +# Documentazione per i Contributori !!! info "Terminologia" - Sei nuovo su DoubleZero? Consulta il [Glossario](glossary.md) per le definizioni dei termini chiave come [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) e [CYOA](glossary.md#cyoa-choose-your-own-adventure). + Nuovo su DoubleZero? Consulta il [Glossario](glossary.md) per le definizioni dei termini chiave come [DZD](glossary.md#dzd-doublezero-device), [DZX](glossary.md#dzx-doublezero-exchange) e [CYOA](glossary.md#cyoa-choose-your-own-adventure). -Benvenuto nella documentazione per i contributor di DoubleZero. Questa sezione copre tutto ciò che serve per diventare un contributor della rete. +Benvenuto nella documentazione per i contributori di DoubleZero. Questa sezione copre tutto ciò che serve per diventare un contributore della rete. -!!! tip "Sei interessato a diventare un contributor della rete?" +!!! tip "Interessato a diventare un contributore della rete?" Consulta la pagina [Requisiti e Architettura](contribute.md) per comprendere l'hardware, la larghezza di banda e la connettività necessari per contribuire alla rete DoubleZero. --- ## Checklist di Onboarding -Usa questa checklist per monitorare i tuoi progressi. **Tutti gli elementi devono essere completati prima che il tuo contributo sia tecnicamente operativo.** +Usa questa checklist per monitorare i tuoi progressi. **Tutti i punti devono essere completati prima che il tuo contributo sia tecnicamente operativo.** ### Fase 1: Prerequisiti -- [ ] CLI di DoubleZero installata su un server di gestione -- [ ] Hardware procurato e conforme ai [requisiti](contribute.md#hardware-requirements) +- [ ] DoubleZero CLI installata su un server di gestione +- [ ] Hardware acquistato e conforme ai [requisiti](contribute.md#hardware-requirements) - [ ] Spazio rack e alimentazione disponibili nel data center (vedi [Rack e Alimentazione](contribute.md#rack-power-requirements)) - [ ] DZD fisicamente installato con connettività di gestione -- [ ] Blocco IPv4 pubblico allocato per il protocollo DZ (**vedi [Regole per i Prefissi DZ](#regole-per-i-prefissi-dz)**) - -### Fase 2: Configurazione dell'Account -- [ ] Coppia di chiavi del servizio generata (`doublezero keygen`) -- [ ] Coppia di chiavi del metrics publisher generata -- [ ] Wallet del rewards manager creato e finanziato con ~0.01 SOL -- [ ] Chiave del servizio, chiave del rewards manager e username GitHub inviati a DZF (solo chiavi pubbliche) -- [ ] Account contributor creato onchain (verificare con `doublezero contributor list`) -- [ ] Chiave del rewards manager registrata onchain da DZF +- [ ] Blocco IPv4 pubblico allocato per il protocollo DZ (**vedi [Regole sui Prefissi DZ](#regole-sui-prefissi-dz)**) + +### Fase 2: Configurazione Account + +Questa fase alterna tra il contributore e DZF. Ogni elemento **DZF** deve essere confermato prima che il gruppo successivo possa iniziare. + +**Contributore** + +- [ ] Nome utente GitHub inviato a DZF + +**DZF** + - [ ] Accesso concesso al repository [malbeclabs/contributors](https://github.com/malbeclabs/contributors) -- [ ] Wallet destinatari e percentuali configurati (**vedi [Gestione delle Ricompense](contribute-rewards.md)**) -- [ ] Ogni wallet destinatario ha un token account 2Z + +**Contributore** + +- [ ] Coppia di chiavi di servizio generata (`doublezero keygen`) +- [ ] Coppia di chiavi del publisher delle metriche generata +- [ ] **Chiave pubblica** della chiave di servizio inviata a DZF + +**DZF** + +- [ ] Account contributore creato onchain + +**Contributore** + +- [ ] Account contributore verificato (`doublezero contributor list`) +- [ ] Gestione delle ricompense configurata (non blocca l'attivazione, **vedi [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management) nel repository dei contributori**) ### Fase 3: Provisioning del Dispositivo -- [ ] Configurazione base del dispositivo applicata (dal repo contributors) +- [ ] Configurazione base del dispositivo applicata (dal repo dei contributori) - [ ] Dispositivo creato onchain (`doublezero device create`) - [ ] Interfacce del dispositivo registrate - [ ] Interfacce loopback create (Loopback255 vpnv4, Loopback256 ipv4) - [ ] Interfacce CYOA/DIA configurate (se dispositivo edge/ibrido) -### Fase 4: Creazione dei Link e Installazione dell'Agent +### Fase 4: Attivazione dei Link e Installazione degli Agent - [ ] Link WAN creati (se applicabile) - [ ] Link DZX creato (stato: `requested`) -- [ ] Link DZX accettato dal contributor peer +- [ ] Link DZX accettato dal contributore peer - [ ] Config Agent installato e in esecuzione - [ ] Config Agent che riceve la configurazione dal controller - [ ] Telemetry Agent installato e in esecuzione -- [ ] Metrics publisher registrato onchain +- [ ] Publisher delle metriche registrato onchain - [ ] Invii di telemetria visibili sul ledger ### Fase 5: Burn-in dei Link - [ ] Tutti i link in drain per un periodo di burn-in di 24 ore -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) mostra zero perdite e zero errori per 24h -- [ ] Link rimossi dal drain dopo un burn-in pulito +- [ ] La [dashboard dello stato dei link](https://data.doublezero.xyz/status/links) mostra zero perdite e zero errori per 24h +- [ ] Link riattivati dopo un burn-in pulito ### Fase 6: Verifica e Attivazione - [ ] `doublezero device list` mostra il tuo dispositivo (con `max_users = 0`) - [ ] `doublezero link list` mostra i tuoi link - [ ] I log del Config Agent mostrano pull di configurazione riusciti - [ ] I log del Telemetry Agent mostrano invii di metriche riusciti -- [ ] **Coordinarsi con DZ/Malbec Labs** per eseguire il test di connettività (connessione, ricezione delle rotte, routing su DZ) +- [ ] **Coordinamento con DZ/Malbec Labs** per eseguire il test di connettività (connessione, ricezione rotte, instradamento su DZ) - [ ] Dopo il superamento del test, impostare `max_users` a 96 tramite `doublezero device update` --- -## Ottenere Aiuto +## Ottenere Supporto -Come parte dell'onboarding, DZF ti aggiungerà ai canali Slack per i contributor: +Come parte dell'onboarding, DZF ti aggiungerà ai canali Slack per i contributori: | Canale | Scopo | |--------|-------| -| **#dz-contributor-announcements** | Comunicazioni ufficiali da DZF e Malbec Labs — aggiornamenti CLI/agent, breaking changes, annunci di sicurezza. Monitora per aggiornamenti critici; fai domande nei thread. | -| **#dz-contributor-incidents** | Eventi non pianificati con impatto sul servizio. Gli incidenti vengono pubblicati automaticamente tramite API/form web con severità e dispositivi/link interessati. Discussione e troubleshooting nei thread. | -| **#dz-contributor-maintenance** | Attività di manutenzione pianificata (aggiornamenti, riparazioni). Programmate tramite API/form web con orari di inizio/fine previsti. Discussione nei thread. | -| **#dz-contributor-ops** | Discussione aperta per tutti i contributor — domande operative, aiuto sulla CLI, condivisione di runbook e playbook. | +| **#dz-contributor-announcements** | Comunicazioni ufficiali da DZF e Malbec Labs — aggiornamenti CLI/agent, breaking change, annunci di sicurezza. Monitora per aggiornamenti critici; fai domande nei thread. | +| **#dz-contributor-incidents** | Eventi non pianificati con impatto sul servizio. Gli incidenti vengono pubblicati automaticamente tramite API/modulo web con severità e dispositivi/link interessati. Discussione e risoluzione nei thread. | +| **#dz-contributor-maintenance** | Attività di manutenzione pianificata (aggiornamenti, riparazioni). Programmate tramite API/modulo web con orari di inizio/fine pianificati. Discussione nei thread. | +| **#dz-contributor-ops** | Discussione aperta per tutti i contributori — domande operative, aiuto con la CLI, condivisione di runbook e playbook. | -Riceverai anche un **canale privato DZ/Malbec Labs** per supporto diretto alla tua organizzazione. +Riceverai anche un **canale privato DZ/Malbec Labs** per il supporto diretto alla tua organizzazione. --- -## Regole per i Prefissi DZ +## Regole sui Prefissi DZ !!! warning "Critico: Utilizzo del Pool di Prefissi DZ" Il pool di prefissi DZ che fornisci è **gestito dal protocollo DoubleZero per l'allocazione degli IP**. **Come vengono utilizzati i prefissi DZ:** - - **Primo IP**: Riservato per il tuo dispositivo (assegnato all'interfaccia Loopback100) - - **IP rimanenti**: Allocati a specifici tipi di utenti che si connettono al tuo DZD: + - **Primo IP**: Riservato al tuo dispositivo (assegnato all'interfaccia Loopback100) + - **IP rimanenti**: Allocati a tipi specifici di utenti che si connettono al tuo DZD: - Utenti `IBRLWithAllocatedIP` - Utenti `EdgeFiltering` - Publisher multicast - - **Utenti IBRL**: NON consumano da questo pool (usano il proprio IP pubblico) + - **Utenti IBRL**: NON consumano da questo pool (utilizzano il proprio IP pubblico) - **NON puoi usare questi indirizzi per:** + **NON puoi utilizzare questi indirizzi per:** - Le tue apparecchiature di rete - Link punto-punto sulle interfacce DIA @@ -107,31 +123,31 @@ Riceverai anche un **canale privato DZ/Malbec Labs** per supporto diretto alla t **Requisiti:** - Devono essere indirizzi IPv4 **globalmente instradabili (pubblici)** - - I range IP privati (10.x, 172.16-31.x, 192.168.x) vengono rifiutati dallo smart contract - - **Dimensione minima: /29** (8 indirizzi), prefissi più grandi preferiti (es., /28, /27) + - Gli intervalli IP privati (10.x, 172.16-31.x, 192.168.x) vengono rifiutati dallo smart contract + - **Dimensione minima: /29** (8 indirizzi), prefissi più grandi preferibili (es. /28, /27) - L'intero blocco deve essere disponibile - non pre-allocare alcun indirizzo - Se hai bisogno di indirizzi per le tue apparecchiature (IP delle interfacce DIA, gestione, ecc.), usa un **pool di indirizzi separato**. + Se hai bisogno di indirizzi per le tue apparecchiature (IP interfaccia DIA, gestione, ecc.), utilizza un **pool di indirizzi separato**. --- ## Riferimento Rapido: Termini Chiave -Sei nuovo su DoubleZero? Ecco i termini essenziali (vedi il [Glossario completo](glossary.md)): +Nuovo su DoubleZero? Ecco i termini essenziali (vedi il [Glossario completo](glossary.md)): | Termine | Definizione | -|---------|------------| +|---------|-------------| | **DZD** | DoubleZero Device - il tuo switch fisico Arista che esegue gli agent DZ | -| **DZX** | DoubleZero Exchange - punto di interconnessione metro dove i contributor fanno peering | +| **DZX** | DoubleZero Exchange - punto di interconnessione metropolitano dove i contributori si interconnettono | | **CYOA** | Choose Your Own Adventure - metodo di connettività utente (GREOverDIA, GREOverFabric, ecc.) | | **DIA** | Direct Internet Access - connettività internet richiesta da tutti i DZD per controller e telemetria, comunemente usata come tipo CYOA per la connettività utente su dispositivi edge/ibridi | -| **WAN Link** | Link tra i tuoi DZD (stesso contributor) | -| **DZX Link** | Link verso il DZD di un altro contributor (richiede accettazione reciproca) | +| **WAN Link** | Link tra i tuoi DZD (stesso contributore) | +| **DZX Link** | Link verso il DZD di un altro contributore (richiede accettazione reciproca) | | **Config Agent** | Interroga il controller, applica la configurazione al tuo DZD | | **Telemetry Agent** | Raccoglie metriche di latenza/perdita TWAMP, le invia al ledger onchain | -| **Service Key** | La tua chiave di identità come contributor per le operazioni CLI | -| **Metrics Publisher Key** | Chiave per firmare gli invii di telemetria onchain | -| **Rewards Manager Key** | Chiave che controlla quali wallet ricevono le tue ricompense | +| **Service Key** | La tua chiave di identità contributore per le operazioni CLI | +| **Metrics Publisher Key** | Chiave per la firma degli invii di telemetria onchain | +| **Rewards Manager Key** | Chiave che controlla quali wallet ricevono le tue ricompense (vedi il repository dei contributori) | --- @@ -142,23 +158,22 @@ Sei nuovo su DoubleZero? Ecco i termini essenziali (vedi il [Glossario completo] | Guida | Descrizione | |-------|-------------| | [Requisiti e Architettura](contribute.md) | Specifiche hardware, architettura di rete, opzioni di larghezza di banda | -| [Provisioning del Dispositivo](contribute-provisioning.md) | Passo dopo passo: chiavi → accesso al repo → dispositivo → link → agent | -| [Gestione delle Ricompense](contribute-rewards.md) | Configurazione dei wallet che ricevono le tue ricompense 2Z | -| [Operazioni](contribute-operations.md) | Aggiornamenti degli agent, gestione dei link, monitoraggio | -| [Deployment di Geoprobe](contribute-geolocation.md) | Deploy e configurazione degli agent geoProbe per la geolocalizzazione | -| [Glossario](glossary.md) | Tutta la terminologia di DoubleZero definita | +| [Provisioning del Dispositivo](contribute-provisioning.md) | Passo dopo passo: accesso al repo → chiavi → dispositivo → link → agent | +| [Operazioni](contribute-operations.md) | Aggiornamenti agent, gestione link, monitoraggio | +| [Deployment di Geoprobe](contribute-geolocation.md) | Deployment e configurazione degli agent geoProbe per la geolocalizzazione | +| [Glossario](glossary.md) | Tutta la terminologia DoubleZero definita | --- -## Fondamenti di Rete per Non-Ingegneri di Rete +## Nozioni di Rete per Non Ingegneri di Rete Se non hai un background di ingegneria di rete, ecco un'introduzione ai concetti utilizzati in questa documentazione: ### Indirizzamento IP -- **Indirizzo IPv4**: Un identificatore univoco per un dispositivo su una rete (es., `192.168.1.1`) -- **Notazione CIDR** (`/29`, `/24`): Indica la dimensione della subnet. `/29` = 8 indirizzi, `/24` = 256 indirizzi -- **IP Pubblico**: Instradabile su internet; **IP Privato**: Solo reti interne (10.x, 172.16-31.x, 192.168.x) +- **Indirizzo IPv4**: Un identificatore univoco per un dispositivo su una rete (es. `192.168.1.1`) +- **Notazione CIDR** (`/29`, `/24`): Indica la dimensione della sottorete. `/29` = 8 indirizzi, `/24` = 256 indirizzi +- **IP pubblico**: Instradabile su internet; **IP privato**: Solo reti interne (10.x, 172.16-31.x, 192.168.x) ### Livelli di Rete @@ -177,8 +192,8 @@ Se non hai un background di ingegneria di rete, ecco un'introduzione ai concetti ### Specifici di DoubleZero -- **Onchain**: In DoubleZero, le registrazioni dei dispositivi, le configurazioni dei link e la telemetria vengono registrate sul ledger di DoubleZero — rendendo lo stato della rete trasparente e verificabile da tutti i partecipanti -- **Controller**: Servizio che deriva la configurazione del DZD dallo stato onchain sul ledger di DoubleZero +- **Onchain**: In DoubleZero, le registrazioni dei dispositivi, le configurazioni dei link e la telemetria vengono registrate sul ledger DoubleZero — rendendo lo stato della rete trasparente e verificabile da tutti i partecipanti +- **Controller**: Servizio che deriva la configurazione del DZD dallo stato onchain sul ledger DoubleZero --- diff --git a/docs/contribute-overview.ja.md b/docs/contribute-overview.ja.md index 0139a91..bd2a552 100644 --- a/docs/contribute-overview.ja.md +++ b/docs/contribute-overview.ja.md @@ -5,133 +5,149 @@ description: DoubleZeroネットワークコントリビューターになるた # コントリビュータードキュメント !!! info "用語について" - DoubleZeroは初めてですか？[用語集](glossary.md)で[DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange)、[CYOA](glossary.md#cyoa-choose-your-own-adventure)などの主要な用語の定義をご覧ください。 + DoubleZeroが初めてですか？[用語集](glossary.md)で[DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange)、[CYOA](glossary.md#cyoa-choose-your-own-adventure)などの主要用語の定義をご確認ください。 -DoubleZeroコントリビュータードキュメントへようこそ。このセクションでは、ネットワークコントリビューターになるために必要なすべてを網羅しています。 +DoubleZeroコントリビュータードキュメントへようこそ。このセクションでは、ネットワークコントリビューターになるために必要なすべてを説明します。 !!! tip "ネットワークコントリビューターに興味がありますか？" - [要件とアーキテクチャ](contribute.md)ページを確認し、DoubleZeroネットワークへの貢献に必要なハードウェア、帯域幅、接続性について理解してください。 + [要件とアーキテクチャ](contribute.md)ページを確認し、DoubleZeroネットワークに貢献するために必要なハードウェア、帯域幅、接続性について理解してください。 --- ## オンボーディングチェックリスト -このチェックリストを使用して進捗を追跡してください。**すべての項目が完了しないと、コントリビューションは技術的に稼働状態になりません。** +このチェックリストを使用して進捗を管理してください。**すべての項目が完了しないと、コントリビューションは技術的に運用可能になりません。** -### フェーズ1: 前提条件 -- [ ] DoubleZero CLIを管理サーバーにインストール済み +### フェーズ1：前提条件 +- [ ] 管理サーバーにDoubleZero CLIをインストール済み - [ ] ハードウェアを調達し、[要件](contribute.md#hardware-requirements)を満たしている - [ ] データセンターのラックスペースと電源が利用可能（[ラックと電源](contribute.md#rack-power-requirements)を参照） -- [ ] DZDが物理的に設置され、管理接続が確立されている -- [ ] DZプロトコル用のパブリックIPv4ブロックが割り当て済み（**[DZプレフィックスルール](#dz-prefix-rules)**を参照） - -### フェーズ2: アカウントセットアップ -- [ ] サービスキーペアを生成済み（`doublezero keygen`） -- [ ] メトリクスパブリッシャーキーペアを生成済み -- [ ] リワードマネージャーウォレットを作成し、約0.01 SOLで入金済み -- [ ] サービスキー、リワードマネージャーキー、GitHubユーザー名をDZFに提出済み（公開鍵のみ） -- [ ] コントリビューターアカウントがオンチェーンに作成済み（`doublezero contributor list`で確認） -- [ ] リワードマネージャーキーがDZFによりオンチェーンに登録済み -- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors)リポジトリへのアクセスが付与済み -- [ ] 受取ウォレットと配分割合を設定済み（**[リワード管理](contribute-rewards.md)**を参照） -- [ ] 各受取ウォレットに2Zトークンアカウントがある - -### フェーズ3: デバイスプロビジョニング -- [ ] 基本デバイス設定を適用済み（contributorsリポジトリから） -- [ ] デバイスをオンチェーンに作成済み（`doublezero device create`） -- [ ] デバイスインターフェースを登録済み -- [ ] ループバックインターフェースを作成済み（Loopback255 vpnv4、Loopback256 ipv4） -- [ ] CYOA/DIAインターフェースを設定済み（エッジ/ハイブリッドデバイスの場合） - -### フェーズ4: リンク確立とエージェントインストール -- [ ] WANリンクを作成済み（該当する場合） -- [ ] DZXリンクを作成済み（ステータス: `requested`） -- [ ] DZXリンクがピアコントリビューターにより承認済み -- [ ] Config Agentをインストールし、稼働中 -- [ ] Config Agentがコントローラーから設定を受信している -- [ ] Telemetry Agentをインストールし、稼働中 -- [ ] メトリクスパブリッシャーをオンチェーンに登録済み -- [ ] テレメトリの送信がレジャーで確認可能 - -### フェーズ5: リンクバーンイン -- [ ] すべてのリンクを24時間のバーンイン期間のためにドレイン済み -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz)で24時間にわたりゼロロス・ゼロエラーが表示されている -- [ ] クリーンなバーンイン後にリンクのドレインを解除済み - -### フェーズ6: 検証とアクティベーション -- [ ] `doublezero device list`でデバイスが表示される（`max_users = 0`） +- [ ] DZDを物理的に設置し、管理接続を確保済み +- [ ] DZプロトコル用のパブリックIPv4ブロックを割り当て済み（**[DZプレフィックスルール](#dz-prefix-rules)を参照**） + +### フェーズ2：アカウントセットアップ + +このフェーズでは、コントリビューターとDZFが交互に作業を行います。各 **DZF** 項目は、次のグループを開始する前に確認される必要があります。 + +**コントリビューター** + +- [ ] GitHubユーザー名をDZFに送付 + +**DZF** + +- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors)リポジトリへのアクセスを付与 + +**コントリビューター** + +- [ ] サービスキーペアを生成（`doublezero keygen`） +- [ ] メトリクスパブリッシャーキーペアを生成 +- [ ] サービスキーの**公開鍵**をDZFに送付 + +**DZF** + +- [ ] コントリビューターアカウントをオンチェーンで作成 + +**コントリビューター** + +- [ ] コントリビューターアカウントを確認（`doublezero contributor list`） +- [ ] 報酬管理を設定（稼働開始をブロックしません。**コントリビューターリポジトリの[報酬管理](https://github.com/malbeclabs/contributors#rewards-management)を参照**） + +### フェーズ3：デバイスプロビジョニング +- [ ] 基本デバイス設定を適用（コントリビューターリポジトリから） +- [ ] デバイスをオンチェーンで作成（`doublezero device create`） +- [ ] デバイスインターフェースを登録 +- [ ] ループバックインターフェースを作成（Loopback255 vpnv4、Loopback256 ipv4） +- [ ] CYOA/DIAインターフェースを設定（エッジ/ハイブリッドデバイスの場合） + +### フェーズ4：リンク確立とエージェントインストール +- [ ] WANリンクを作成（該当する場合） +- [ ] DZXリンクを作成（ステータス：`requested`） +- [ ] ピアコントリビューターがDZXリンクを承認 +- [ ] Config Agentをインストールして稼働中 +- [ ] Config Agentがコントローラーから設定を受信中 +- [ ] Telemetry Agentをインストールして稼働中 +- [ ] メトリクスパブリッシャーをオンチェーンで登録 +- [ ] テレメトリ送信がレジャー上で確認可能 + +### フェーズ5：リンクバーンイン +- [ ] すべてのリンクを24時間のバーンイン期間中ドレイン +- [ ] [リンクステータスダッシュボード](https://data.doublezero.xyz/status/links)で24時間ゼロロスかつゼロエラーを確認 +- [ ] クリーンなバーンイン後にリンクのドレインを解除 + +### フェーズ6：検証とアクティベーション +- [ ] `doublezero device list`でデバイスが表示される（`max_users = 0`の状態） - [ ] `doublezero link list`でリンクが表示される -- [ ] Config Agentのログに設定プルの成功が記録されている -- [ ] Telemetry Agentのログにメトリクス送信の成功が記録されている +- [ ] Config Agentのログで設定プルの成功を確認 +- [ ] Telemetry Agentのログでメトリクス送信の成功を確認 - [ ] **DZ/Malbec Labsと連携**して接続テストを実施（接続、ルート受信、DZ経由のルーティング） - [ ] テスト合格後、`doublezero device update`で`max_users`を96に設定 --- -## サポートの利用 +## サポートを受ける オンボーディングの一環として、DZFがコントリビューターSlackチャンネルに追加します： | チャンネル | 目的 | |---------|---------| -| **#dz-contributor-announcements** | DZFおよびMalbec Labsからの公式コミュニケーション — CLI/エージェントのアップグレード、破壊的変更、セキュリティアナウンス。重要なアップデートを監視し、質問はスレッドで行ってください。 | -| **#dz-contributor-incidents** | 計画外のサービス影響イベント。インシデントはAPI/ウェブフォーム経由で重大度と影響を受けるデバイス/リンクとともに自動的に投稿されます。議論とトラブルシューティングはスレッドで行います。 | -| **#dz-contributor-maintenance** | 計画的なメンテナンス活動（アップグレード、修理）。API/ウェブフォーム経由で計画開始/終了時刻とともにスケジュールされます。議論はスレッドで行います。 | -| **#dz-contributor-ops** | すべてのコントリビューター向けのオープンディスカッション — 運用に関する質問、CLIヘルプ、ランブックやプレイブックの共有。 | +| **#dz-contributor-announcements** | DZFおよびMalbec Labsからの公式コミュニケーション — CLI/エージェントのアップグレード、破壊的変更、セキュリティアナウンス。重要な更新を監視し、スレッドで質問してください。 | +| **#dz-contributor-incidents** | 計画外のサービス影響イベント。インシデントは重大度と影響を受けるデバイス/リンクとともにAPI/Webフォーム経由で自動投稿されます。議論とトラブルシューティングはスレッドで行われます。 | +| **#dz-contributor-maintenance** | 計画メンテナンス活動（アップグレード、修理）。API/Webフォーム経由で計画開始/終了時刻とともにスケジュールされます。議論はスレッドで行われます。 | +| **#dz-contributor-ops** | すべてのコントリビューター向けのオープンディスカッション — 運用に関する質問、CLIのヘルプ、ランブックやプレイブックの共有。 | -また、組織向けの直接サポートのための**プライベートDZ/Malbec Labsチャンネル**も提供されます。 +また、組織向けの直接サポート用に**プライベートDZ/Malbec Labsチャンネル**も提供されます。 --- ## DZプレフィックスルール -!!! warning "重要: DZプレフィックスプールの使用について" - 提供するDZプレフィックスプールは、**IP割り当てのためにDoubleZeroプロトコルが管理します**。 +!!! warning "重要：DZプレフィックスプールの使用" + 提供するDZプレフィックスプールは、**IPアロケーションのためにDoubleZeroプロトコルによって管理されます**。 **DZプレフィックスの使用方法：** - - **最初のIP**: デバイス用に予約（Loopback100インターフェースに割り当て） - - **残りのIP**: DZDに接続する特定のユーザータイプに割り当て： - - `IBRLWithAllocatedIP` ユーザー - - `EdgeFiltering` ユーザー + - **最初のIP**：デバイス用に予約（Loopback100インターフェースに割り当て） + - **残りのIP**：DZDに接続する特定のユーザータイプに割り当て： + - `IBRLWithAllocatedIP`ユーザー + - `EdgeFiltering`ユーザー - マルチキャストパブリッシャー - - **IBRLユーザー**: このプールからは消費しません（独自のパブリックIPを使用） + - **IBRLユーザー**：このプールからは消費しません（独自のパブリックIPを使用） - **以下の用途には使用できません：** + **これらのアドレスを以下の目的に使用することはできません：** - 自身のネットワーク機器 - DIAインターフェースのポイントツーポイントリンク - 管理インターフェース - - DZプロトコル外のあらゆるインフラストラクチャ + - DZプロトコル外のインフラストラクチャ **要件：** - - **グローバルにルーティング可能な（パブリック）** IPv4アドレスである必要があります - - プライベートIPレンジ（10.x、172.16-31.x、192.168.x）はスマートコントラクトにより拒否されます - - **最小サイズ: /29**（8アドレス）、より大きなプレフィックスが推奨されます（例: /28、/27） - - ブロック全体が利用可能である必要があります - アドレスを事前に割り当てないでください + - **グローバルにルーティング可能（パブリック）**なIPv4アドレスであること + - プライベートIPレンジ（10.x、172.16-31.x、192.168.x）はスマートコントラクトによって拒否されます + - **最小サイズ：/29**（8アドレス）、より大きなプレフィックスが推奨（例：/28、/27） + - ブロック全体が利用可能であること - アドレスを事前に割り当てないでください 自身の機器用のアドレス（DIAインターフェースIP、管理用など）が必要な場合は、**別のアドレスプール**を使用してください。 --- -## クイックリファレンス: 主要用語 +## クイックリファレンス：主要用語 -DoubleZeroは初めてですか？以下が基本的な用語です（[完全な用語集](glossary.md)を参照）： +DoubleZeroが初めてですか？以下が基本用語です（[完全な用語集](glossary.md)を参照）： | 用語 | 定義 | |------|------------| -| **DZD** | DoubleZero Device - DZエージェントを実行する物理的なArista スイッチ | -| **DZX** | DoubleZero Exchange - コントリビューター同士がピアリングするメトロ相互接続ポイント | -| **CYOA** | Choose Your Own Adventure - ユーザー接続方法（GREOverDIA、GREOverFabricなど） | -| **DIA** | Direct Internet Access - コントローラーとテレメトリのためにすべてのDZDに必要なインターネット接続。エッジ/ハイブリッドデバイスではユーザー接続用のCYOAタイプとしてもよく使用されます | +| **DZD** | DoubleZero Device - DZエージェントを実行する物理的なAristaスイッチ | +| **DZX** | DoubleZero Exchange - コントリビューターがピアリングするメトロ相互接続ポイント | +| **CYOA** | Choose Your Own Adventure - ユーザー接続方式（GREOverDIA、GREOverFabricなど） | +| **DIA** | Direct Internet Access - すべてのDZDがコントローラーおよびテレメトリ用に必要とするインターネット接続。エッジ/ハイブリッドデバイスでのユーザー接続用CYOAタイプとしても一般的に使用 | | **WAN Link** | 自身のDZD間のリンク（同一コントリビューター） | | **DZX Link** | 別のコントリビューターのDZDへのリンク（相互承認が必要） | -| **Config Agent** | コントローラーをポーリングし、DZDに設定を適用するエージェント | -| **Telemetry Agent** | TWAMPレイテンシ/ロスメトリクスを収集し、オンチェーンレジャーに送信するエージェント | +| **Config Agent** | コントローラーをポーリングし、DZDに設定を適用 | +| **Telemetry Agent** | TWAMPレイテンシ/ロスメトリクスを収集し、オンチェーンレジャーに送信 | | **Service Key** | CLI操作用のコントリビューターIDキー | -| **Metrics Publisher Key** | オンチェーンのテレメトリ送信に署名するためのキー | -| **Rewards Manager Key** | リワードを受け取るウォレットを管理するキー | +| **Metrics Publisher Key** | テレメトリ送信をオンチェーンで署名するためのキー | +| **Rewards Manager Key** | 報酬を受け取るウォレットを制御するキー（コントリビューターリポジトリを参照） | --- @@ -142,44 +158,43 @@ DoubleZeroは初めてですか？以下が基本的な用語です（[完全な | ガイド | 説明 | |-------|-------------| | [要件とアーキテクチャ](contribute.md) | ハードウェア仕様、ネットワークアーキテクチャ、帯域幅オプション | -| [デバイスプロビジョニング](contribute-provisioning.md) | ステップバイステップ: キー → リポジトリアクセス → デバイス → リンク → エージェント | -| [リワード管理](contribute-rewards.md) | 2Zリワードを受け取るウォレットの設定 | +| [デバイスプロビジョニング](contribute-provisioning.md) | ステップバイステップ：リポジトリアクセス → キー → デバイス → リンク → エージェント | | [運用](contribute-operations.md) | エージェントアップグレード、リンク管理、モニタリング | -| [Geoプローブデプロイメント](contribute-geolocation.md) | ジオロケーション用のgeoProbeエージェントのデプロイと設定 | -| [用語集](glossary.md) | DoubleZeroの全用語定義 | +| [Geoプローブデプロイ](contribute-geolocation.md) | ジオロケーション用geoProbeエージェントのデプロイと設定 | +| [用語集](glossary.md) | すべてのDoubleZero用語の定義 | --- -## ネットワークエンジニア以外の方向けのネットワーク基礎 +## ネットワークエンジニア以外の方向けのネットワーク基礎知識 -ネットワークエンジニアリングのバックグラウンドがない方向けに、このドキュメントで使用される概念の入門ガイドを紹介します： +ネットワークエンジニアリングのバックグラウンドをお持ちでない方のために、本ドキュメントで使用される概念の入門を以下に示します： ### IPアドレッシング -- **IPv4アドレス**: ネットワーク上のデバイスの一意な識別子（例: `192.168.1.1`） -- **CIDR表記**（`/29`、`/24`）: サブネットのサイズを示します。`/29` = 8アドレス、`/24` = 256アドレス -- **パブリックIP**: インターネット上でルーティング可能；**プライベートIP**: 内部ネットワーク専用（10.x、172.16-31.x、192.168.x） +- **IPv4アドレス**：ネットワーク上のデバイスの一意の識別子（例：`192.168.1.1`） +- **CIDR表記**（`/29`、`/24`）：サブネットサイズを示す。`/29` = 8アドレス、`/24` = 256アドレス +- **パブリックIP**：インターネット上でルーティング可能；**プライベートIP**：内部ネットワーク専用（10.x、172.16-31.x、192.168.x） ### ネットワークレイヤー -- **レイヤー1（物理層）**: ケーブル、光学機器、波長 -- **レイヤー2（データリンク層）**: スイッチ、VLAN、MACアドレス -- **レイヤー3（ネットワーク層）**: ルーター、IPアドレス、ルーティングプロトコル +- **レイヤー1（物理層）**：ケーブル、光学部品、波長 +- **レイヤー2（データリンク層）**：スイッチ、VLAN、MACアドレス +- **レイヤー3（ネットワーク層）**：ルーター、IPアドレス、ルーティングプロトコル ### 一般的な用語 -- **MTU**: Maximum Transmission Unit（最大転送単位）- 最大パケットサイズ（WANリンクでは通常9000バイト） -- **VLAN**: Virtual LAN - 共有インフラストラクチャ上でトラフィックを論理的に分離 -- **VRF**: Virtual Routing and Forwarding - 同一デバイス上でルーティングテーブルを分離 -- **BGP**: Border Gateway Protocol - ネットワーク間のルート交換プロトコル -- **GRE**: Generic Routing Encapsulation - オーバーレイネットワーク用のトンネリングプロトコル -- **TWAMP**: Two-Way Active Measurement Protocol - デバイス間のレイテンシ/ロスを測定するプロトコル +- **MTU**：Maximum Transmission Unit - 最大パケットサイズ（WANリンクでは通常9000バイト） +- **VLAN**：Virtual LAN - 共有インフラストラクチャ上でトラフィックを論理的に分離 +- **VRF**：Virtual Routing and Forwarding - 同一デバイス上でルーティングテーブルを分離 +- **BGP**：Border Gateway Protocol - ネットワーク間のルート交換 +- **GRE**：Generic Routing Encapsulation - オーバーレイネットワーク用のトンネリングプロトコル +- **TWAMP**：Two-Way Active Measurement Protocol - デバイス間のレイテンシ/ロスを測定 ### DoubleZero固有の用語 -- **オンチェーン**: DoubleZeroでは、デバイスの登録、リンク設定、テレメトリがDoubleZeroレジャーに記録されます — ネットワーク状態をすべての参加者が透過的かつ検証可能にします -- **コントローラー**: DoubleZeroレジャー上のオンチェーン状態からDZDの設定を導出するサービス +- **オンチェーン**：DoubleZeroでは、デバイス登録、リンク設定、テレメトリがDoubleZeroレジャーに記録されます。これにより、ネットワーク状態がすべての参加者に対して透明で検証可能になります +- **コントローラー**：DoubleZeroレジャー上のオンチェーン状態からDZD設定を導出するサービス --- -始める準備はできましたか？[要件とアーキテクチャ](contribute.md)から始めましょう。 \ No newline at end of file +始める準備はできましたか？[要件とアーキテクチャ](contribute.md)から始めてください。 \ No newline at end of file diff --git a/docs/contribute-overview.ko.md b/docs/contribute-overview.ko.md index 2e3daa9..71861b4 100644 --- a/docs/contribute-overview.ko.md +++ b/docs/contribute-overview.ko.md @@ -9,8 +9,8 @@ description: DoubleZero 네트워크 기여자가 되기 위한 개요 및 온 DoubleZero 기여자 문서에 오신 것을 환영합니다. 이 섹션에서는 네트워크 기여자가 되기 위해 필요한 모든 내용을 다룹니다. -!!! tip "네트워크 기여자가 되고 싶으신가요?" - [요구사항 및 아키텍처](contribute.md) 페이지를 검토하여 DoubleZero 네트워크에 기여하는 데 필요한 하드웨어, 대역폭 및 연결 요건을 파악하세요. +!!! tip "네트워크 기여자에 관심이 있으신가요?" + [요구사항 & 아키텍처](contribute.md) 페이지를 검토하여 DoubleZero 네트워크에 기여하는 데 필요한 하드웨어, 대역폭 및 연결 요건을 이해하세요. --- @@ -21,49 +21,65 @@ DoubleZero 기여자 문서에 오신 것을 환영합니다. 이 섹션에서 ### 1단계: 사전 요건 - [ ] 관리 서버에 DoubleZero CLI 설치 완료 - [ ] 하드웨어 조달 및 [요구사항](contribute.md#hardware-requirements) 충족 확인 -- [ ] 데이터 센터 랙 공간 및 전원 확보 ([랙 및 전원](contribute.md#rack-power-requirements) 참조) +- [ ] 데이터센터 랙 공간 및 전원 확보 ([랙 & 전원](contribute.md#rack-power-requirements) 참조) - [ ] DZD 물리적 설치 및 관리 연결 완료 - [ ] DZ 프로토콜용 공인 IPv4 블록 할당 (**[DZ 프리픽스 규칙](#dz-프리픽스-규칙) 참조**) ### 2단계: 계정 설정 + +이 단계는 기여자와 DZF 간에 번갈아 진행됩니다. 각 **DZF** 항목은 다음 그룹을 시작하기 전에 확인되어야 합니다. + +**기여자** + +- [ ] GitHub 사용자명을 DZF에 전송 + +**DZF** + +- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 리포지토리 접근 권한 부여 + +**기여자** + - [ ] 서비스 키페어 생성 (`doublezero keygen`) - [ ] 메트릭 퍼블리셔 키페어 생성 -- [ ] 리워드 매니저 지갑 생성 및 ~0.01 SOL 충전 -- [ ] 서비스 키, 리워드 매니저 키 및 GitHub 사용자명을 DZF에 제출 (공개 키만) -- [ ] 온체인 기여자 계정 생성 (`doublezero contributor list`로 확인) -- [ ] DZF에 의해 온체인 리워드 매니저 키 등록 완료 -- [ ] [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 리포지토리 접근 권한 부여 -- [ ] 수령 지갑 및 비율 설정 (**[리워드 관리](contribute-rewards.md) 참조**) -- [ ] 각 수령 지갑에 2Z 토큰 계정 보유 +- [ ] 서비스 키 **공개키**를 DZF에 전송 + +**DZF** + +- [ ] 온체인에 기여자 계정 생성 + +**기여자** + +- [ ] 기여자 계정 확인 (`doublezero contributor list`) +- [ ] 보상 관리 설정 (라이브 전환을 차단하지 않음, **기여자 리포지토리의 [보상 관리](https://github.com/malbeclabs/contributors#rewards-management) 참조**) ### 3단계: 디바이스 프로비저닝 -- [ ] 기본 디바이스 설정 적용 (contributors 리포지토리에서) -- [ ] 온체인 디바이스 생성 (`doublezero device create`) +- [ ] 기본 디바이스 구성 적용 (기여자 리포지토리에서) +- [ ] 온체인에 디바이스 생성 (`doublezero device create`) - [ ] 디바이스 인터페이스 등록 - [ ] 루프백 인터페이스 생성 (Loopback255 vpnv4, Loopback256 ipv4) -- [ ] CYOA/DIA 인터페이스 설정 (엣지/하이브리드 디바이스인 경우) +- [ ] CYOA/DIA 인터페이스 구성 (엣지/하이브리드 디바이스인 경우) -### 4단계: 링크 설정 및 에이전트 설치 +### 4단계: 링크 수립 & 에이전트 설치 - [ ] WAN 링크 생성 (해당하는 경우) - [ ] DZX 링크 생성 (상태: `requested`) -- [ ] 피어 기여자의 DZX 링크 수락 +- [ ] 피어 기여자에 의해 DZX 링크 수락 - [ ] Config Agent 설치 및 실행 -- [ ] Config Agent가 컨트롤러로부터 설정 수신 +- [ ] Config Agent가 컨트롤러로부터 구성 수신 - [ ] Telemetry Agent 설치 및 실행 -- [ ] 온체인 메트릭 퍼블리셔 등록 +- [ ] 온체인에 메트릭 퍼블리셔 등록 - [ ] 원장에서 텔레메트리 제출 확인 가능 ### 5단계: 링크 번인 - [ ] 24시간 번인 기간 동안 모든 링크 드레인 -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz)에서 24시간 동안 손실 제로 및 오류 제로 확인 -- [ ] 클린 번인 후 링크 드레인 해제 +- [ ] [링크 상태 대시보드](https://data.doublezero.xyz/status/links)에서 24시간 동안 손실 제로 및 오류 제로 확인 +- [ ] 정상 번인 후 링크 드레인 해제 -### 6단계: 검증 및 활성화 -- [ ] `doublezero device list`에서 디바이스 확인 (`max_users = 0`) -- [ ] `doublezero link list`에서 링크 확인 -- [ ] Config Agent 로그에서 설정 풀 성공 확인 +### 6단계: 검증 & 활성화 +- [ ] `doublezero device list`에 디바이스 표시 확인 (`max_users = 0`) +- [ ] `doublezero link list`에 링크 표시 확인 +- [ ] Config Agent 로그에서 구성 풀 성공 확인 - [ ] Telemetry Agent 로그에서 메트릭 제출 성공 확인 -- [ ] **DZ/Malbec Labs와 조율**하여 연결 테스트 실행 (연결, 라우트 수신, DZ를 통한 라우팅) +- [ ] **DZ/Malbec Labs와 협의**하여 연결 테스트 실행 (연결, 라우트 수신, DZ를 통한 라우팅) - [ ] 테스트 통과 후 `doublezero device update`를 통해 `max_users`를 96으로 설정 --- @@ -74,21 +90,21 @@ DoubleZero 기여자 문서에 오신 것을 환영합니다. 이 섹션에서 | 채널 | 목적 | |---------|---------| -| **#dz-contributor-announcements** | DZF 및 Malbec Labs의 공식 커뮤니케이션 — CLI/에이전트 업그레이드, 호환성 변경, 보안 공지. 중요한 업데이트를 모니터링하고 스레드에서 질문하세요. | -| **#dz-contributor-incidents** | 계획되지 않은 서비스 영향 이벤트. 인시던트는 API/웹 양식을 통해 심각도 및 영향받는 디바이스/링크와 함께 자동으로 게시됩니다. 토론 및 트러블슈팅은 스레드에서 진행됩니다. | -| **#dz-contributor-maintenance** | 계획된 유지보수 활동 (업그레이드, 수리). API/웹 양식을 통해 계획된 시작/종료 시간과 함께 예약됩니다. 토론은 스레드에서 진행됩니다. | -| **#dz-contributor-ops** | 모든 기여자를 위한 오픈 토론 — 운영 질문, CLI 도움, 런북 및 플레이북 공유. | +| **#dz-contributor-announcements** | DZF 및 Malbec Labs의 공식 커뮤니케이션 — CLI/에이전트 업그레이드, 호환성 변경사항, 보안 공지. 중요 업데이트를 모니터링하고 스레드에서 질문하세요. | +| **#dz-contributor-incidents** | 계획되지 않은 서비스 영향 이벤트. API/웹 폼을 통해 심각도 및 영향받는 디바이스/링크와 함께 인시던트가 자동으로 게시됩니다. 스레드에서 논의 및 문제 해결이 이루어집니다. | +| **#dz-contributor-maintenance** | 계획된 유지보수 활동 (업그레이드, 수리). API/웹 폼을 통해 계획된 시작/종료 시간으로 예약됩니다. 스레드에서 논의합니다. | +| **#dz-contributor-ops** | 모든 기여자를 위한 개방형 토론 — 운영 질문, CLI 도움, 런북 및 플레이북 공유. | -또한 조직에 대한 직접 지원을 위한 **비공개 DZ/Malbec Labs 채널**도 제공됩니다. +또한 조직에 대한 직접 지원을 위한 **비공개 DZ/Malbec Labs 채널**이 제공됩니다. --- ## DZ 프리픽스 규칙 !!! warning "중요: DZ 프리픽스 풀 사용" - 제공하는 DZ 프리픽스 풀은 **IP 할당을 위해 DoubleZero 프로토콜이 관리합니다**. + 제공하신 DZ 프리픽스 풀은 **IP 할당을 위해 DoubleZero 프로토콜에서 관리합니다**. - **DZ 프리픽스 사용 방식:** + **DZ 프리픽스 사용 방법:** - **첫 번째 IP**: 디바이스용으로 예약 (Loopback100 인터페이스에 할당) - **나머지 IP**: DZD에 연결하는 특정 사용자 유형에 할당: @@ -102,36 +118,36 @@ DoubleZero 기여자 문서에 오신 것을 환영합니다. 이 섹션에서 - 자체 네트워크 장비 - DIA 인터페이스의 포인트-투-포인트 링크 - 관리 인터페이스 - - DZ 프로토콜 외부의 모든 인프라 + - DZ 프로토콜 외부의 인프라 **요구사항:** - - **전역 라우팅 가능한 (공인)** IPv4 주소여야 함 - - 사설 IP 범위 (10.x, 172.16-31.x, 192.168.x)는 스마트 컨트랙트에 의해 거부됨 - - **최소 크기: /29** (8개 주소), 더 큰 프리픽스 권장 (예: /28, /27) - - 전체 블록이 사용 가능해야 함 - 어떤 주소도 사전 할당하지 마세요 + - **글로벌 라우팅 가능한 (공인)** IPv4 주소여야 합니다 + - 사설 IP 범위 (10.x, 172.16-31.x, 192.168.x)는 스마트 컨트랙트에서 거부됩니다 + - **최소 크기: /29** (8개 주소), 더 큰 프리픽스 선호 (예: /28, /27) + - 전체 블록이 사용 가능해야 합니다 - 주소를 사전 할당하지 마세요 - 자체 장비(DIA 인터페이스 IP, 관리 등)에 주소가 필요한 경우 **별도의 주소 풀**을 사용하세요. + 자체 장비용 주소가 필요한 경우 (DIA 인터페이스 IP, 관리 등), **별도의 주소 풀**을 사용하세요. --- ## 빠른 참조: 주요 용어 -DoubleZero가 처음이신가요? 다음은 필수 용어입니다 ([전체 용어집](glossary.md) 참조): +DoubleZero가 처음이신가요? 필수 용어를 확인하세요 ([전체 용어집](glossary.md) 참조): | 용어 | 정의 | |------|------------| | **DZD** | DoubleZero Device - DZ 에이전트를 실행하는 물리적 Arista 스위치 | -| **DZX** | DoubleZero Exchange - 기여자들이 피어링하는 메트로 인터커넥트 포인트 | +| **DZX** | DoubleZero Exchange - 기여자들이 피어링하는 메트로 상호접속 지점 | | **CYOA** | Choose Your Own Adventure - 사용자 연결 방식 (GREOverDIA, GREOverFabric 등) | -| **DIA** | Direct Internet Access - 컨트롤러 및 텔레메트리를 위해 모든 DZD에 필요한 인터넷 연결, 엣지/하이브리드 디바이스에서 사용자 연결을 위한 CYOA 유형으로 일반적으로 사용됨 | +| **DIA** | Direct Internet Access - 컨트롤러 및 텔레메트리를 위해 모든 DZD에 필요한 인터넷 연결, 엣지/하이브리드 디바이스에서 사용자 연결을 위한 CYOA 유형으로 일반적으로 사용 | | **WAN Link** | 자체 DZD 간의 링크 (동일 기여자) | | **DZX Link** | 다른 기여자의 DZD로의 링크 (상호 수락 필요) | -| **Config Agent** | 컨트롤러를 폴링하고 DZD에 설정을 적용 | -| **Telemetry Agent** | TWAMP 지연/손실 메트릭을 수집하고 온체인 원장에 제출 | -| **Service Key** | CLI 작업을 위한 기여자 신원 키 | +| **Config Agent** | 컨트롤러를 폴링하여 DZD에 구성을 적용 | +| **Telemetry Agent** | TWAMP 지연/손실 메트릭을 수집하여 온체인 원장에 제출 | +| **Service Key** | CLI 운영을 위한 기여자 신원 키 | | **Metrics Publisher Key** | 온체인 텔레메트리 제출 서명을 위한 키 | -| **Rewards Manager Key** | 리워드를 수령할 지갑을 제어하는 키 | +| **Rewards Manager Key** | 보상을 수령할 지갑을 제어하는 키 (기여자 리포지토리 참조) | --- @@ -141,45 +157,44 @@ DoubleZero가 처음이신가요? 다음은 필수 용어입니다 ([전체 용 | 가이드 | 설명 | |-------|-------------| -| [요구사항 및 아키텍처](contribute.md) | 하드웨어 사양, 네트워크 아키텍처, 대역폭 옵션 | -| [디바이스 프로비저닝](contribute-provisioning.md) | 단계별: 키 → 리포지토리 접근 → 디바이스 → 링크 → 에이전트 | -| [리워드 관리](contribute-rewards.md) | 2Z 리워드를 수령할 지갑 설정 | +| [요구사항 & 아키텍처](contribute.md) | 하드웨어 사양, 네트워크 아키텍처, 대역폭 옵션 | +| [디바이스 프로비저닝](contribute-provisioning.md) | 단계별: 리포지토리 접근 → 키 → 디바이스 → 링크 → 에이전트 | | [운영](contribute-operations.md) | 에이전트 업그레이드, 링크 관리, 모니터링 | -| [Geoprobe 배포](contribute-geolocation.md) | 지오로케이션을 위한 geoProbe 에이전트 배포 및 설정 | +| [Geoprobe 배포](contribute-geolocation.md) | 지리적 위치 확인을 위한 geoProbe 에이전트 배포 및 구성 | | [용어집](glossary.md) | 모든 DoubleZero 용어 정의 | --- -## 비네트워크 엔지니어를 위한 네트워크 기초 +## 비 네트워크 엔지니어를 위한 네트워크 기초 -네트워크 엔지니어링 배경이 아닌 경우, 이 문서에서 사용되는 개념에 대한 입문 가이드입니다: +네트워크 엔지니어링 배경이 아닌 분들을 위해 이 문서에서 사용되는 개념에 대한 입문 안내입니다: ### IP 주소 지정 -- **IPv4 주소**: 네트워크에서 디바이스의 고유 식별자 (예: `192.168.1.1`) -- **CIDR 표기법** (`/29`, `/24`): 서브넷 크기를 나타냄. `/29` = 8개 주소, `/24` = 256개 주소 +- **IPv4 주소**: 네트워크상의 디바이스를 위한 고유 식별자 (예: `192.168.1.1`) +- **CIDR 표기법** (`/29`, `/24`): 서브넷 크기를 나타냅니다. `/29` = 8개 주소, `/24` = 256개 주소 - **공인 IP**: 인터넷에서 라우팅 가능; **사설 IP**: 내부 네트워크 전용 (10.x, 172.16-31.x, 192.168.x) ### 네트워크 계층 -- **레이어 1 (물리 계층)**: 케이블, 광학 장치, 파장 -- **레이어 2 (데이터 링크 계층)**: 스위치, VLAN, MAC 주소 -- **레이어 3 (네트워크 계층)**: 라우터, IP 주소, 라우팅 프로토콜 +- **계층 1 (물리 계층)**: 케이블, 광학 장치, 파장 +- **계층 2 (데이터 링크 계층)**: 스위치, VLAN, MAC 주소 +- **계층 3 (네트워크 계층)**: 라우터, IP 주소, 라우팅 프로토콜 ### 일반 용어 -- **MTU**: Maximum Transmission Unit - 최대 패킷 크기 (일반적으로 WAN 링크의 경우 9000바이트) +- **MTU**: Maximum Transmission Unit - 최대 패킷 크기 (WAN 링크의 경우 일반적으로 9000바이트) - **VLAN**: Virtual LAN - 공유 인프라에서 트래픽을 논리적으로 분리 - **VRF**: Virtual Routing and Forwarding - 동일 디바이스에서 라우팅 테이블을 격리 - **BGP**: Border Gateway Protocol - 네트워크 간 라우트 교환 -- **GRE**: Generic Routing Encapsulation - 오버레이 네트워크를 위한 터널링 프로토콜 +- **GRE**: Generic Routing Encapsulation - 오버레이 네트워크용 터널링 프로토콜 - **TWAMP**: Two-Way Active Measurement Protocol - 디바이스 간 지연/손실 측정 -### DoubleZero 관련 용어 +### DoubleZero 전용 용어 -- **온체인**: DoubleZero에서 디바이스 등록, 링크 설정 및 텔레메트리는 DoubleZero 원장에 기록됩니다 — 네트워크 상태를 모든 참여자가 투명하고 검증 가능하게 합니다 -- **컨트롤러**: DoubleZero 원장의 온체인 상태로부터 DZD 설정을 도출하는 서비스 +- **온체인**: DoubleZero에서 디바이스 등록, 링크 구성 및 텔레메트리는 DoubleZero 원장에 기록되어 — 네트워크 상태가 모든 참여자에게 투명하고 검증 가능합니다 +- **컨트롤러**: DoubleZero 원장의 온체인 상태로부터 DZD 구성을 도출하는 서비스 --- -시작할 준비가 되셨나요? [요구사항 및 아키텍처](contribute.md)부터 시작하세요. \ No newline at end of file +시작할 준비가 되셨나요? [요구사항 & 아키텍처](contribute.md)부터 시작하세요. \ No newline at end of file diff --git a/docs/contribute-overview.pt.md b/docs/contribute-overview.pt.md index 032d815..b57444a 100644 --- a/docs/contribute-overview.pt.md +++ b/docs/contribute-overview.pt.md @@ -10,7 +10,7 @@ description: Visão geral e checklist de integração para se tornar um contribu Bem-vindo à documentação do contribuidor do DoubleZero. Esta seção cobre tudo o que você precisa para se tornar um contribuidor da rede. !!! tip "Interessado em se tornar um contribuidor da rede?" - Consulte a página [Requisitos e Arquitetura](contribute.md) para entender o hardware, a largura de banda e a conectividade necessários para contribuir com a rede DoubleZero. + Revise a página [Requisitos e Arquitetura](contribute.md) para entender o hardware, largura de banda e conectividade necessários para contribuir com a rede DoubleZero. --- @@ -20,43 +20,59 @@ Use este checklist para acompanhar seu progresso. **Todos os itens devem ser con ### Fase 1: Pré-requisitos - [ ] DoubleZero CLI instalado em um servidor de gerenciamento -- [ ] Hardware adquirido e atendendo aos [requisitos](contribute.md#hardware-requirements) +- [ ] Hardware adquirido e atende aos [requisitos](contribute.md#hardware-requirements) - [ ] Espaço em rack e energia disponíveis no data center (veja [Rack e Energia](contribute.md#rack-power-requirements)) - [ ] DZD fisicamente instalado com conectividade de gerenciamento -- [ ] Bloco de IPv4 público alocado para o protocolo DZ (**veja [Regras de Prefixo DZ](#regras-de-prefixo-dz)**) +- [ ] Bloco público IPv4 alocado para o protocolo DZ (**veja [Regras de Prefixo DZ](#regras-de-prefixo-dz)**) + +### Fase 2: Configuração da Conta + +Esta fase alterna entre o contribuidor e a DZF. Cada item **DZF** deve ser confirmado antes que o próximo grupo possa começar. + +**Contribuidor** + +- [ ] Nome de usuário do GitHub enviado para a DZF + +**DZF** + +- [ ] Acesso concedido ao repositório [malbeclabs/contributors](https://github.com/malbeclabs/contributors) + +**Contribuidor** -### Fase 2: Configuração de Conta - [ ] Par de chaves de serviço gerado (`doublezero keygen`) - [ ] Par de chaves do publicador de métricas gerado -- [ ] Carteira do gerenciador de recompensas criada e financiada com ~0.01 SOL -- [ ] Chave de serviço, chave do gerenciador de recompensas e nome de usuário do GitHub enviados à DZF (apenas chaves públicas) -- [ ] Conta de contribuidor criada onchain (verificar com `doublezero contributor list`) -- [ ] Chave do gerenciador de recompensas registrada onchain pela DZF -- [ ] Acesso concedido ao repositório [malbeclabs/contributors](https://github.com/malbeclabs/contributors) -- [ ] Carteiras destinatárias e percentuais configurados (**veja [Gerenciamento de Recompensas](contribute-rewards.md)**) -- [ ] Cada carteira destinatária possui uma conta de token 2Z +- [ ] **Chave pública** da chave de serviço enviada para a DZF + +**DZF** + +- [ ] Conta do contribuidor criada onchain -### Fase 3: Provisionamento de Dispositivo -- [ ] Configuração base do dispositivo aplicada (do repositório contributors) +**Contribuidor** + +- [ ] Conta do contribuidor verificada (`doublezero contributor list`) +- [ ] Gerenciamento de recompensas configurado (não bloqueia a entrada em produção, **veja [Gerenciamento de Recompensas](https://github.com/malbeclabs/contributors#rewards-management) no repositório de contribuidores**) + +### Fase 3: Provisionamento do Dispositivo +- [ ] Configuração base do dispositivo aplicada (do repositório de contribuidores) - [ ] Dispositivo criado onchain (`doublezero device create`) - [ ] Interfaces do dispositivo registradas - [ ] Interfaces de loopback criadas (Loopback255 vpnv4, Loopback256 ipv4) - [ ] Interfaces CYOA/DIA configuradas (se dispositivo edge/híbrido) -### Fase 4: Estabelecimento de Links e Instalação de Agentes +### Fase 4: Estabelecimento de Links e Instalação do Agente - [ ] Links WAN criados (se aplicável) - [ ] Link DZX criado (status: `requested`) - [ ] Link DZX aceito pelo contribuidor par - [ ] Config Agent instalado e em execução -- [ ] Config Agent recebendo configuração do controller +- [ ] Config Agent recebendo configuração do controlador - [ ] Telemetry Agent instalado e em execução - [ ] Publicador de métricas registrado onchain - [ ] Submissões de telemetria visíveis no ledger -### Fase 5: Período de Teste dos Links -- [ ] Todos os links drenados para período de teste de 24 horas -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) mostra zero perda e zero erros por 24h -- [ ] Links restaurados após teste limpo +### Fase 5: Burn-in dos Links +- [ ] Todos os links drenados para período de burn-in de 24 horas +- [ ] [Painel de status dos links](https://data.doublezero.xyz/status/links) mostra zero perda e zero erros por 24h +- [ ] Links restaurados após burn-in limpo ### Fase 6: Verificação e Ativação - [ ] `doublezero device list` mostra seu dispositivo (com `max_users = 0`) @@ -64,19 +80,19 @@ Use este checklist para acompanhar seu progresso. **Todos os itens devem ser con - [ ] Logs do Config Agent mostram pulls de configuração bem-sucedidos - [ ] Logs do Telemetry Agent mostram submissões de métricas bem-sucedidas - [ ] **Coordenar com DZ/Malbec Labs** para executar teste de conectividade (conectar, receber rotas, rotear pelo DZ) -- [ ] Após aprovação no teste, definir `max_users` para 96 via `doublezero device update` +- [ ] Após o teste passar, definir `max_users` para 96 via `doublezero device update` --- ## Obtendo Ajuda -Como parte da integração, a DZF adicionará você aos canais do Slack para contribuidores: +Como parte da integração, a DZF adicionará você aos canais Slack de contribuidores: -| Canal | Finalidade | -|-------|------------| -| **#dz-contributor-announcements** | Comunicações oficiais da DZF e Malbec Labs — atualizações de CLI/agentes, mudanças incompatíveis, avisos de segurança. Monitore para atualizações críticas; faça perguntas em threads. | -| **#dz-contributor-incidents** | Eventos não planejados com impacto no serviço. Incidentes são publicados automaticamente via API/formulário web com severidade e dispositivos/links afetados. Discussão e troubleshooting acontecem em threads. | -| **#dz-contributor-maintenance** | Atividades de manutenção planejada (upgrades, reparos). Agendadas via API/formulário web com horários planejados de início/fim. Discussão em threads. | +| Canal | Propósito | +|-------|-----------| +| **#dz-contributor-announcements** | Comunicações oficiais da DZF e Malbec Labs — atualizações de CLI/agente, mudanças incompatíveis, anúncios de segurança. Monitore para atualizações críticas; faça perguntas em threads. | +| **#dz-contributor-incidents** | Eventos não planejados com impacto no serviço. Incidentes são publicados automaticamente via API/formulário web com severidade e dispositivos/links afetados. Discussão e resolução de problemas acontecem em threads. | +| **#dz-contributor-maintenance** | Atividades de manutenção planejada (atualizações, reparos). Agendadas via API/formulário web com horários planejados de início/fim. Discussão em threads. | | **#dz-contributor-ops** | Discussão aberta para todos os contribuidores — perguntas operacionais, ajuda com CLI, compartilhamento de runbooks e playbooks. | Você também receberá um **canal privado DZ/Malbec Labs** para suporte direto à sua organização. @@ -88,10 +104,10 @@ Você também receberá um **canal privado DZ/Malbec Labs** para suporte direto !!! warning "Crítico: Uso do Pool de Prefixos DZ" O pool de prefixos DZ que você fornece é **gerenciado pelo protocolo DoubleZero para alocação de IP**. - **Como os prefixos DZ são usados:** + **Como os prefixos DZ são utilizados:** - **Primeiro IP**: Reservado para seu dispositivo (atribuído à interface Loopback100) - - **IPs restantes**: Alocados para tipos específicos de usuários que se conectam ao seu DZD: + - **IPs restantes**: Alocados para tipos específicos de usuários conectando ao seu DZD: - Usuários `IBRLWithAllocatedIP` - Usuários `EdgeFiltering` - Publicadores multicast @@ -99,7 +115,7 @@ Você também receberá um **canal privado DZ/Malbec Labs** para suporte direto **Você NÃO PODE usar esses endereços para:** - - Seu próprio equipamento de rede + - Seus próprios equipamentos de rede - Links ponto a ponto em interfaces DIA - Interfaces de gerenciamento - Qualquer infraestrutura fora do protocolo DZ @@ -107,11 +123,11 @@ Você também receberá um **canal privado DZ/Malbec Labs** para suporte direto **Requisitos:** - Devem ser endereços IPv4 **globalmente roteáveis (públicos)** - - Faixas de IP privado (10.x, 172.16-31.x, 192.168.x) são rejeitadas pelo smart contract + - Faixas de IP privadas (10.x, 172.16-31.x, 192.168.x) são rejeitadas pelo smart contract - **Tamanho mínimo: /29** (8 endereços), prefixos maiores são preferíveis (ex.: /28, /27) - O bloco inteiro deve estar disponível - não pré-aloque nenhum endereço - Se você precisar de endereços para seu próprio equipamento (IPs de interface DIA, gerenciamento, etc.), use um **pool de endereços separado**. + Se você precisar de endereços para seus próprios equipamentos (IPs de interface DIA, gerenciamento, etc.), use um **pool de endereços separado**. --- @@ -121,17 +137,17 @@ Novo no DoubleZero? Aqui estão os termos essenciais (veja o [Glossário complet | Termo | Definição | |-------|-----------| -| **DZD** | DoubleZero Device - seu switch físico Arista executando agentes DZ | -| **DZX** | DoubleZero Exchange - ponto de interconexão metropolitana onde contribuidores fazem peering | +| **DZD** | DoubleZero Device - seu switch Arista físico executando agentes DZ | +| **DZX** | DoubleZero Exchange - ponto de interconexão metropolitano onde contribuidores fazem peering | | **CYOA** | Choose Your Own Adventure - método de conectividade do usuário (GREOverDIA, GREOverFabric, etc.) | -| **DIA** | Direct Internet Access - conectividade com a internet exigida por todos os DZDs para controller e telemetria, comumente usado como tipo CYOA para conectividade de usuários em dispositivos edge/híbridos | +| **DIA** | Direct Internet Access - conectividade à internet exigida por todos os DZDs para controlador e telemetria, comumente usado como tipo CYOA para conectividade de usuários em dispositivos edge/híbridos | | **WAN Link** | Link entre seus próprios DZDs (mesmo contribuidor) | | **DZX Link** | Link para o DZD de outro contribuidor (requer aceitação mútua) | -| **Config Agent** | Consulta o controller, aplica configuração ao seu DZD | +| **Config Agent** | Consulta o controlador, aplica configuração ao seu DZD | | **Telemetry Agent** | Coleta métricas de latência/perda TWAMP, submete ao ledger onchain | | **Service Key** | Sua chave de identidade de contribuidor para operações via CLI | | **Metrics Publisher Key** | Chave para assinar submissões de telemetria onchain | -| **Rewards Manager Key** | Chave que controla quais carteiras recebem suas recompensas | +| **Rewards Manager Key** | Chave que controla quais carteiras recebem suas recompensas (veja o repositório de contribuidores) | --- @@ -142,17 +158,16 @@ Novo no DoubleZero? Aqui estão os termos essenciais (veja o [Glossário complet | Guia | Descrição | |------|-----------| | [Requisitos e Arquitetura](contribute.md) | Especificações de hardware, arquitetura de rede, opções de largura de banda | -| [Provisionamento de Dispositivo](contribute-provisioning.md) | Passo a passo: chaves → acesso ao repositório → dispositivo → links → agentes | -| [Gerenciamento de Recompensas](contribute-rewards.md) | Configurando as carteiras que recebem suas recompensas 2Z | +| [Provisionamento do Dispositivo](contribute-provisioning.md) | Passo a passo: acesso ao repositório → chaves → dispositivo → links → agentes | | [Operações](contribute-operations.md) | Atualizações de agentes, gerenciamento de links, monitoramento | | [Implantação do Geoprobe](contribute-geolocation.md) | Implantação e configuração de agentes geoProbe para geolocalização | -| [Glossário](glossary.md) | Toda a terminologia do DoubleZero definida | +| [Glossário](glossary.md) | Toda a terminologia DoubleZero definida | --- -## Conceitos Básicos de Rede para Não-Engenheiros de Rede +## Fundamentos de Rede para Não-Engenheiros de Rede -Se você não tem formação em engenharia de redes, aqui está uma introdução aos conceitos usados nesta documentação: +Se você não tem experiência em engenharia de redes, aqui está uma introdução aos conceitos utilizados nesta documentação: ### Endereçamento IP @@ -162,7 +177,7 @@ Se você não tem formação em engenharia de redes, aqui está uma introdução ### Camadas de Rede -- **Camada 1 (Física)**: Cabos, óptica, comprimentos de onda +- **Camada 1 (Física)**: Cabos, ópticas, comprimentos de onda - **Camada 2 (Enlace de Dados)**: Switches, VLANs, endereços MAC - **Camada 3 (Rede)**: Roteadores, endereços IP, protocolos de roteamento @@ -178,7 +193,7 @@ Se você não tem formação em engenharia de redes, aqui está uma introdução ### Específico do DoubleZero - **Onchain**: No DoubleZero, registros de dispositivos, configurações de links e telemetria são registrados no ledger do DoubleZero — tornando o estado da rede transparente e verificável por todos os participantes -- **Controller**: Serviço que deriva a configuração do DZD a partir do estado onchain no ledger do DoubleZero +- **Controlador**: Serviço que deriva a configuração do DZD a partir do estado onchain no ledger do DoubleZero --- diff --git a/docs/contribute-overview.zh.md b/docs/contribute-overview.zh.md index 42f8fba..c99f625 100644 --- a/docs/contribute-overview.zh.md +++ b/docs/contribute-overview.zh.md @@ -5,7 +5,7 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 # 贡献者文档 !!! info "术语说明" - 初次接触 DoubleZero？请参阅[术语表](glossary.md)了解关键术语的定义，如 [DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange) 和 [CYOA](glossary.md#cyoa-choose-your-own-adventure)。 + 初次接触 DoubleZero？请参阅[术语表](glossary.md)了解关键术语定义，如 [DZD](glossary.md#dzd-doublezero-device)、[DZX](glossary.md#dzx-doublezero-exchange) 和 [CYOA](glossary.md#cyoa-choose-your-own-adventure)。 欢迎阅读 DoubleZero 贡献者文档。本节涵盖了成为网络贡献者所需的全部内容。 @@ -16,25 +16,41 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 ## 入门清单 -使用此清单跟踪您的进度。**所有项目必须全部完成，您的贡献才能在技术上正式运行。** +使用此清单跟踪您的进度。**在您的贡献正式投入技术运行之前，所有项目必须全部完成。** -### 阶段 1：前提条件 +### 阶段 1：前置条件 - [ ] 在管理服务器上安装 DoubleZero CLI -- [ ] 已采购硬件并满足[要求](contribute.md#hardware-requirements) +- [ ] 硬件已采购并满足[要求](contribute.md#hardware-requirements) - [ ] 数据中心机架空间和电力已就绪（参见[机架与电力](contribute.md#rack-power-requirements)） - [ ] DZD 已物理安装并具备管理连接 -- [ ] 已分配用于 DZ 协议的公共 IPv4 地址块（**参见 [DZ 前缀规则](#dz-prefix-rules)**） +- [ ] 已分配用于 DZ 协议的公网 IPv4 地址块（**参见 [DZ 前缀规则](#dz-prefix-rules)**） ### 阶段 2：账户设置 + +此阶段由贡献者和 DZF 交替完成。每个 **DZF** 项目必须确认完成后，下一组才能开始。 + +**贡献者** + +- [ ] 将 GitHub 用户名发送给 DZF + +**DZF** + +- [ ] 已授予 [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 仓库的访问权限 + +**贡献者** + - [ ] 已生成服务密钥对（`doublezero keygen`） - [ ] 已生成指标发布者密钥对 -- [ ] 已创建奖励管理器钱包并充入约 0.01 SOL -- [ ] 已向 DZF 提交服务密钥、奖励管理器密钥和 GitHub 用户名（仅公钥） -- [ ] 贡献者账户已在链上创建（通过 `doublezero contributor list` 验证） -- [ ] 奖励管理器密钥已由 DZF 在链上注册 -- [ ] 已获得 [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 仓库的访问权限 -- [ ] 已配置接收钱包和百分比（**参见[奖励管理](contribute-rewards.md)**） -- [ ] 每个接收钱包都有一个 2Z 代币账户 +- [ ] 已将服务密钥的**公钥**发送给 DZF + +**DZF** + +- [ ] 已在链上创建贡献者账户 + +**贡献者** + +- [ ] 已验证贡献者账户（`doublezero contributor list`） +- [ ] 已设置奖励管理（不影响上线，**参见贡献者仓库中的 [Rewards Management](https://github.com/malbeclabs/contributors#rewards-management)**） ### 阶段 3：设备配置 - [ ] 已应用基础设备配置（来自 contributors 仓库） @@ -43,7 +59,7 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 - [ ] 已创建环回接口（Loopback255 vpnv4、Loopback256 ipv4） - [ ] 已配置 CYOA/DIA 接口（如果是边缘/混合设备） -### 阶段 4：链路建立与 Agent 安装 +### 阶段 4：链路建立与代理安装 - [ ] 已创建 WAN 链路（如适用） - [ ] 已创建 DZX 链路（状态：`requested`） - [ ] DZX 链路已被对端贡献者接受 @@ -53,10 +69,10 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 - [ ] 指标发布者已在链上注册 - [ ] 遥测提交在账本上可见 -### 阶段 5：链路老化测试 -- [ ] 所有链路已排空，进行 24 小时老化测试 -- [ ] [metrics.doublezero.xyz](https://metrics.doublezero.xyz) 显示 24 小时内零丢包和零错误 -- [ ] 老化测试通过后取消链路排空 +### 阶段 5：链路烧机测试 +- [ ] 所有链路已排空，进行 24 小时烧机测试 +- [ ] [链路状态仪表板](https://data.doublezero.xyz/status/links)显示 24 小时内零丢包和零错误 +- [ ] 烧机测试通过后取消链路排空 ### 阶段 6：验证与激活 - [ ] `doublezero device list` 显示您的设备（`max_users = 0`） @@ -74,12 +90,12 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 | 频道 | 用途 | |---------|---------| -| **#dz-contributor-announcements** | 来自 DZF 和 Malbec Labs 的官方通知 — CLI/Agent 升级、破坏性变更、安全公告。请关注关键更新；在帖子中提问。 | -| **#dz-contributor-incidents** | 非计划性服务影响事件。事件通过 API/Web 表单自动发布，包含严重程度和受影响的设备/链路。在帖子中进行讨论和故障排除。 | -| **#dz-contributor-maintenance** | 计划维护活动（升级、维修）。通过 API/Web 表单安排，包含计划开始/结束时间。在帖子中讨论。 | -| **#dz-contributor-ops** | 面向所有贡献者的开放讨论 — 运维问题、CLI 帮助、分享运维手册和操作指南。 | +| **#dz-contributor-announcements** | 来自 DZF 和 Malbec Labs 的官方通信 — CLI/代理升级、破坏性变更、安全公告。请关注重要更新；在消息线程中提问。 | +| **#dz-contributor-incidents** | 计划外的影响服务的事件。事件通过 API/网页表单自动发布，包含严重程度和受影响的设备/链路。讨论和故障排除在消息线程中进行。 | +| **#dz-contributor-maintenance** | 计划维护活动（升级、修复）。通过 API/网页表单安排，包含计划的开始/结束时间。讨论在消息线程中进行。 | +| **#dz-contributor-ops** | 所有贡献者的开放讨论 — 运维问题、CLI 帮助、分享运维手册和操作指南。 | -您还将获得一个**私有的 DZ/Malbec Labs 频道**，为您的组织提供直接支持。 +您还将获得一个**专属的 DZ/Malbec Labs 私有频道**，为您的组织提供直接支持。 --- @@ -95,7 +111,7 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 - `IBRLWithAllocatedIP` 用户 - `EdgeFiltering` 用户 - 组播发布者 - - **IBRL 用户**：不从此池中消耗（他们使用自己的公共 IP） + - **IBRL 用户**：不消耗此池中的地址（他们使用自己的公网 IP） **您不能将这些地址用于：** @@ -106,32 +122,32 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 **要求：** - - 必须是**全球可路由（公共）**的 IPv4 地址 + - 必须是**全球可路由（公网）**的 IPv4 地址 - 私有 IP 范围（10.x、172.16-31.x、192.168.x）会被智能合约拒绝 - - **最小大小：/29**（8 个地址），建议使用更大的前缀（例如 /28、/27） - - 整个地址块必须可用 - 请勿预先分配任何地址 + - **最小规格：/29**（8 个地址），建议使用更大的前缀（如 /28、/27） + - 整个地址块必须可用 - 不要预先分配任何地址 - 如果您需要地址用于自己的设备（DIA 接口 IP、管理等），请使用**单独的地址池**。 + 如果您需要为自己的设备（DIA 接口 IP、管理等）分配地址，请使用**单独的地址池**。 --- ## 快速参考：关键术语 -初次接触 DoubleZero？以下是核心术语（参见[完整术语表](glossary.md)）： +初次接触 DoubleZero？以下是基本术语（参见[完整术语表](glossary.md)）： | 术语 | 定义 | |------|------------| -| **DZD** | DoubleZero Device - 运行 DZ Agent 的物理 Arista 交换机 | -| **DZX** | DoubleZero Exchange - 贡献者之间互联的城域交换点 | +| **DZD** | DoubleZero Device - 运行 DZ 代理的物理 Arista 交换机 | +| **DZX** | DoubleZero Exchange - 贡献者进行对等互联的城域交换点 | | **CYOA** | Choose Your Own Adventure - 用户连接方式（GREOverDIA、GREOverFabric 等） | -| **DIA** | Direct Internet Access - 所有 DZD 所需的互联网连接，用于控制器和遥测；也常作为边缘/混合设备上用户连接的 CYOA 类型 | +| **DIA** | Direct Internet Access - 所有 DZD 用于控制器和遥测所需的互联网连接，通常也作为边缘/混合设备上用户连接的 CYOA 类型 | | **WAN Link** | 您自己的 DZD 之间的链路（同一贡献者） | -| **DZX Link** | 连接到其他贡献者 DZD 的链路（需要双方接受） | +| **DZX Link** | 连接到另一个贡献者 DZD 的链路（需要双方接受） | | **Config Agent** | 轮询控制器，将配置应用到您的 DZD | | **Telemetry Agent** | 收集 TWAMP 延迟/丢包指标，提交到链上账本 | -| **Service Key** | 您的贡献者身份密钥，用于 CLI 操作 | +| **Service Key** | 用于 CLI 操作的贡献者身份密钥 | | **Metrics Publisher Key** | 用于在链上签署遥测提交的密钥 | -| **Rewards Manager Key** | 控制哪些钱包接收您奖励的密钥 | +| **Rewards Manager Key** | 控制哪些钱包接收您奖励的密钥（参见贡献者仓库） | --- @@ -142,23 +158,22 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 | 指南 | 描述 | |-------|-------------| | [要求与架构](contribute.md) | 硬件规格、网络架构、带宽选项 | -| [设备配置](contribute-provisioning.md) | 分步指南：密钥 → 仓库访问 → 设备 → 链路 → Agent | -| [奖励管理](contribute-rewards.md) | 设置接收 2Z 奖励的钱包 | -| [运维操作](contribute-operations.md) | Agent 升级、链路管理、监控 | -| [Geoprobe 部署](contribute-geolocation.md) | 部署和配置 geoProbe Agent 以实现地理定位 | +| [设备配置](contribute-provisioning.md) | 分步指南：仓库访问 → 密钥 → 设备 → 链路 → 代理 | +| [运维操作](contribute-operations.md) | 代理升级、链路管理、监控 | +| [Geoprobe 部署](contribute-geolocation.md) | 部署和配置 geoProbe 代理用于地理定位 | | [术语表](glossary.md) | 所有 DoubleZero 术语定义 | --- -## 面向非网络工程师的网络基础知识 +## 非网络工程师的网络基础知识 -如果您没有网络工程背景，以下是本文档中使用的概念入门： +如果您没有网络工程背景，以下是本文档中使用的概念入门介绍： ### IP 地址 - **IPv4 地址**：网络上设备的唯一标识符（例如 `192.168.1.1`） - **CIDR 表示法**（`/29`、`/24`）：表示子网大小。`/29` = 8 个地址，`/24` = 256 个地址 -- **公共 IP**：可在互联网上路由；**私有 IP**：仅限内部网络（10.x、172.16-31.x、192.168.x） +- **公网 IP**：可在互联网上路由；**私有 IP**：仅限内部网络使用（10.x、172.16-31.x、192.168.x） ### 网络层次 @@ -170,15 +185,15 @@ description: 成为 DoubleZero 网络贡献者的概述和入门清单。 - **MTU**：最大传输单元 - 最大数据包大小（WAN 链路通常为 9000 字节） - **VLAN**：虚拟局域网 - 在共享基础设施上逻辑隔离流量 -- **VRF**：虚拟路由和转发 - 在同一设备上隔离路由表 +- **VRF**：虚拟路由转发 - 在同一设备上隔离路由表 - **BGP**：边界网关协议 - 网络间路由交换 - **GRE**：通用路由封装 - 用于覆盖网络的隧道协议 -- **TWAMP**：双向主动测量协议 - 测量设备间的延迟/丢包 +- **TWAMP**：双向主动测量协议 - 测量设备之间的延迟/丢包 -### DoubleZero 特定术语 +### DoubleZero 特有概念 -- **链上**：在 DoubleZero 中，设备注册、链路配置和遥测数据都记录在 DoubleZero 账本上 — 使网络状态对所有参与者透明且可验证 -- **控制器**：从 DoubleZero 账本上的链上状态生成 DZD 配置的服务 +- **链上（Onchain）**：在 DoubleZero 中，设备注册、链路配置和遥测数据都记录在 DoubleZero 账本上 — 使网络状态对所有参与者透明且可验证 +- **控制器（Controller）**：从 DoubleZero 账本上的链上状态派生 DZD 配置的服务 --- diff --git a/docs/contribute-provisioning.es.md b/docs/contribute-provisioning.es.md index 77a33b2..c422b4f 100644 --- a/docs/contribute-provisioning.es.md +++ b/docs/contribute-provisioning.es.md @@ -1,71 +1,71 @@ --- -description: Guía paso a paso para aprovisionar un Dispositivo DoubleZero (DZD) y registrar sus interfaces y roles en la cadena. +description: Guía paso a paso para aprovisionar un Dispositivo DoubleZero (DZD) y registrar sus interfaces y roles on-chain. --- # Guía de Aprovisionamiento de Dispositivos -Esta guía te acompaña a través del aprovisionamiento de un Dispositivo DoubleZero (DZD) de principio a fin. Cada fase corresponde a la [Lista de Verificación de Incorporación](contribute-overview.md#onboarding-checklist). +Esta guía le lleva paso a paso a través del aprovisionamiento de un Dispositivo DoubleZero (DZD) de principio a fin. Cada fase corresponde a la [Lista de Verificación de Incorporación](contribute-overview.md#onboarding-checklist). --- ## Cómo Encaja Todo -Esta guía te acompaña a través del registro de tu infraestructura en la cadena para que la red DoubleZero pueda enrutar tráfico a través de ella. Cuanto más completamente esté registrado tu dispositivo, más útil será para la red. Una representación completa en la cadena de tu dispositivo permite una mejor resolución de problemas, planificación de capacidad, y permite al controlador tomar decisiones informadas. Con el tiempo, el objetivo es que el controlador asuma más responsabilidad de configuración. +Esta guía le lleva a través del registro de su infraestructura on-chain para que la red DoubleZero pueda enrutar tráfico a través de ella. Cuanto más completo sea el registro de su dispositivo, más útil será para la red. Una representación on-chain completa de su dispositivo permite una mejor resolución de problemas, planificación de capacidad y permite al controlador tomar decisiones informadas. Con el tiempo, el objetivo es que el controlador asuma más responsabilidad en la configuración. ### Conceptos clave **Interfaces** -Las interfaces en un DZD vienen en diferentes formas: puertos Ethernet, canales de puertos (LAGs compuestos por múltiples puertos Ethernet) y loopbacks. Cada interfaz que desempeña un rol en la red necesita ser registrada en la cadena con las banderas apropiadas para que el protocolo sepa qué hace. +Las interfaces en un DZD vienen en diferentes formas: puertos Ethernet, canales de puertos (LAGs compuestos por múltiples puertos Ethernet) y loopbacks. Cada interfaz que desempeña un rol en la red necesita ser registrada on-chain con las banderas apropiadas para que el protocolo sepa qué función cumple. -Los puertos Ethernet y canales de puertos pueden cumplir los siguientes roles: +Los puertos Ethernet y los canales de puertos pueden cumplir los siguientes roles: | Bandera | Qué significa | |---------|---------------| -| `--interface-dia dia` | Marca la interfaz como el enlace ascendente de acceso directo a internet | +| `--interface-dia dia` | Marca la interfaz como enlace ascendente de acceso directo a internet | | `--interface-cyoa ` | Declara cómo los usuarios establecen túneles GRE a través de esta interfaz (p. ej., por internet público, mediante un enlace de peering privado) | -| `--user-tunnel-endpoint true` | Esta interfaz lleva una IP pública en la que los usuarios terminan túneles GRE | +| `--user-tunnel-endpoint true` | Esta interfaz lleva una IP pública donde los usuarios terminan túneles GRE | -Las interfaces usadas para enlaces WAN o DZX no llevan una bandera específica, se registran con su ancho de banda y luego se referencian cuando se crea el enlace. +Las interfaces utilizadas para enlaces WAN o DZX no llevan una bandera específica; se registran con su ancho de banda y luego se referencian cuando se crea el enlace. -Las interfaces loopback sirven para varios propósitos: +Las interfaces loopback cumplen varios propósitos: | Loopback | Qué significa | |----------|---------------| -| **Loopback100 / 101** | Llevan IPs públicas en las que los usuarios terminan túneles GRE. Se registran con `--user-tunnel-endpoint true`. | -| **Loopback255** (`vpnv4`) | Se registra para que el controlador pueda asignar una IP usada para el ID de router BGP, peering VPN-IPv4 (unicast), identidad IS-IS y enrutamiento por segmentos | -| **Loopback256** (`ipv4`) | Se registra para que el controlador pueda asignar una IP usada para peering BGP IPv4 (multicast) y sesiones MSDP | +| **Loopback100 / 101** | Llevan IPs públicas donde los usuarios terminan túneles GRE. Se registran con `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Se registra para que el controlador pueda asignar una IP utilizada para el ID de router BGP, peering VPN-IPv4 (unicast), identidad IS-IS y segment routing | +| **Loopback256** (`ipv4`) | Se registra para que el controlador pueda asignar una IP utilizada para peering BGP IPv4 (multicast) y sesiones MSDP | **Enlaces** -Los enlaces se registran por separado de las interfaces, y las interfaces deben existir en la cadena antes de que un enlace pueda referenciarlas. Cuando creas un enlace WAN o DZX, especificas una interfaz ya registrada como el punto final físico del enlace. No todas las interfaces están vinculadas a un enlace: las interfaces DIA, CYOA y loopback no están conectadas a un enlace. +Los enlaces se registran por separado de las interfaces, y las interfaces deben existir on-chain antes de que un enlace pueda referenciarlas. Cuando crea un enlace WAN o DZX, especifica una interfaz ya registrada como punto final físico del enlace. No todas las interfaces están vinculadas a un enlace: las interfaces DIA, CYOA y loopback no están conectadas a un enlace. | Término | Qué significa | |---------|---------------| -| **Enlace WAN** | Un enlace entre dos de tus propios DZDs | -| **Enlace DZX** | Un enlace entre tu DZD y el DZD de otro contribuidor | +| **Enlace WAN** | Un enlace entre dos de sus propios DZDs | +| **Enlace DZX** | Un enlace entre su DZD y el DZD de otro contribuidor | ### Visión general de la arquitectura ```mermaid flowchart TB subgraph Onchain - SC[Registro DoubleZero] + SC[Libro Mayor DoubleZero] end - subgraph Tu Infraestructura + subgraph Your Infrastructure MGMT[Servidor de Gestión
CLI DoubleZero] - subgraph DZD[Tu DZD] - CYOA["Interfaz DIA · CYOA
(enlace ascendente hacia usuarios)"] + subgraph DZD[Su DZD] + CYOA["Interfaz DIA · CYOA
(enlace ascendente orientado al usuario)"] WAN_INTF["Interfaz de enlace WAN"] DZX_INTF["Interfaz de enlace DZX"] LO100["Loopback100/101
(endpoint de túnel de usuario)"] end - DZD2[Tu otro DZD] + DZD2[Su otro DZD] end - subgraph Otro Contribuidor - OtherDZD[Su DZD] + subgraph Other Contributor + OtherDZD[DZD de otro contribuidor] end USERS["Usuarios"] @@ -79,24 +79,24 @@ flowchart TB --- -## Fase 1: Requisitos Previos +## Fase 1: Prerrequisitos -Antes de poder aprovisionar un dispositivo, necesitas tener el hardware físico configurado y algunas direcciones IP asignadas. +Antes de poder aprovisionar un dispositivo, necesita tener el hardware físico configurado y algunas direcciones IP asignadas. -### Lo Que Necesitas +### Lo Que Necesita | Requisito | Por Qué Se Necesita | |-----------|---------------------| | **Hardware DZD** | Switch Arista 7280CR3A (ver [especificaciones de hardware](contribute.md#hardware-requirements)) | -| **Espacio en Rack** | 1U por DZD, con flujo de aire adecuado. Ver [Rack y Alimentación](contribute.md#rack-power-requirements) | +| **Espacio en Rack** | 2U reservados por DZD (1U en uso actualmente), con flujo de aire adecuado. Ver [Rack y Alimentación](contribute.md#rack-power-requirements) | | **Alimentación** | Dos alimentaciones independientes, cada una capaz de soportar toda la carga por sí sola. Ver [Rack y Alimentación](contribute.md#rack-power-requirements) | | **Acceso de Gestión** | Acceso SSH/consola para configurar el switch | -| **Conectividad a Internet** | Para publicar métricas y obtener configuración del controlador | +| **Conectividad a Internet** | Para publicación de métricas y obtención de configuración del controlador | | **Bloque IPv4 Público** | Mínimo /29 para el pool de prefijos DZ (ver abajo) | ### Instalar el CLI de DoubleZero -El CLI de DoubleZero (`doublezero`) se usa durante todo el aprovisionamiento para registrar dispositivos, crear enlaces y gestionar tu contribución. Debe instalarse en un **servidor de gestión o VM** — no en el switch DZD. El switch solo ejecuta el Agente de Configuración y el Agente de Telemetría (instalados en la [Fase 4](#fase-4-establecimiento-de-enlaces-e-instalación-de-agentes)). +El CLI de DoubleZero (`doublezero`) se utiliza a lo largo del aprovisionamiento para registrar dispositivos, crear enlaces y gestionar su contribución. Debe instalarse en un **servidor de gestión o VM** — no en el switch DZD en sí. El switch solo ejecuta el Agente de Configuración y el Agente de Telemetría (instalados en la [Fase 4](#phase-4-link-establishment-agent-installation)). **Ubuntu / Debian:** ```bash @@ -110,42 +110,42 @@ curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.rpm.sh | sudo yum install doublezero ``` -Verifica que el demonio esté ejecutándose: +Verifique que el demonio está en ejecución: ```bash sudo systemctl status doublezerod ``` -### Entendiendo Tu Prefijo DZ +### Comprender Su Prefijo DZ -Tu prefijo DZ es un bloque de direcciones IP públicas que el protocolo DoubleZero gestiona para la asignación de IPs. +Su prefijo DZ es un bloque de direcciones IP públicas que el protocolo DoubleZero gestiona para la asignación de IPs. ```mermaid flowchart LR - subgraph "Tu Bloque /29 (8 IPs)" - IP1["Primera IP
Reservada para
tu dispositivo"] + subgraph "Su Bloque /29 (8 IPs)" + IP1["Primera IP
Reservada para
su dispositivo"] IP2["IP 2"] IP3["IP 3"] IP4["..."] IP8["IP 8"] end - IP1 -->|Asignada a| LO[Loopback100
en tu DZD] + IP1 -->|Asignada a| LO[Loopback100
en su DZD] IP2 -->|Asignada a| U1[Usuario 1] IP3 -->|Asignada a| U2[Usuario 2] ``` -**Cómo se usan los prefijos DZ:** +**Cómo se utilizan los prefijos DZ:** -- **Primera IP**: Reservada para tu dispositivo (asignada a la interfaz Loopback100) -- **IPs restantes**: Asignadas a tipos específicos de usuarios que se conectan a tu DZD: +- **Primera IP**: Reservada para su dispositivo (asignada a la interfaz Loopback100) +- **IPs restantes**: Asignadas a tipos específicos de usuarios que se conectan a su DZD: - Usuarios `IBRLWithAllocatedIP` - Usuarios `EdgeFiltering` (caso de uso futuro) - **Usuarios IBRL**: NO consumen de este pool (usan su propia IP pública) !!! warning "Reglas del Prefijo DZ" - **NO PUEDES usar estas direcciones para:** + **NO PUEDE usar estas direcciones para:** - - Tu propio equipo de red + - Su propio equipamiento de red - Enlaces punto a punto en interfaces DIA - Interfaces de gestión - Cualquier infraestructura fuera del protocolo DZ @@ -155,31 +155,31 @@ flowchart LR - Deben ser direcciones IPv4 **enrutables globalmente (públicas)** - Los rangos de IP privados (10.x, 172.16-31.x, 192.168.x) son rechazados por el contrato inteligente - **Tamaño mínimo: /29** (8 direcciones), se prefieren prefijos más grandes (p. ej., /28, /27) - - El bloque completo debe estar disponible — no preasignes ninguna dirección + - El bloque completo debe estar disponible — no pre-asigne ninguna dirección - Si necesitas direcciones para tu propio equipo (IPs de interfaz DIA, gestión, etc.), usa un **pool de direcciones separado**. + Si necesita direcciones para su propio equipamiento (IPs de interfaz DIA, gestión, etc.), use un **pool de direcciones separado**. --- ## Fase 2: Configuración de Cuenta -En esta fase, creas las claves criptográficas que te identifican a ti y a tus dispositivos en la red, e indicas dónde deben pagarse tus recompensas. +En esta fase, crea las claves criptográficas que le identifican a usted y a sus dispositivos en la red, y configura la gestión de recompensas. -Tres claves resultan de esta fase: una clave de servicio, una clave de publicador de métricas y una clave de gestor de recompensas. Envía las claves públicas de las tres a DZF juntas en el [Paso 2.4](#paso-24-enviar-claves-a-dzf). [Gestión de Recompensas](contribute-rewards.md) cubre completamente el lado de las recompensas. +Los pasos se ejecutan en este orden por una razón: primero el acceso al repositorio, porque el repositorio contiene las instrucciones para los pasos posteriores, luego sus claves, luego las recompensas. Algunos pasos necesitan que DZF actúe antes de que pueda continuar, y cada uno de los siguientes lo indica. ### Dónde Ejecutar el CLI -!!! warning "NO instales el CLI en tu switch" - El CLI de DoubleZero (`doublezero`) debe instalarse en un **servidor de gestión o VM**, no en tu switch Arista. +!!! warning "NO instale el CLI en su switch" + El CLI de DoubleZero (`doublezero`) debe instalarse en un **servidor de gestión o VM**, no en su switch Arista. ```mermaid flowchart LR subgraph "Servidor de Gestión/VM" CLI[CLI DoubleZero] - KEYS[Tus Pares de Claves] + KEYS[Sus Pares de Claves] end - subgraph "Tu Switch DZD" + subgraph "Su Switch DZD" CA[Agente de Configuración] TA[Agente de Telemetría] end @@ -190,130 +190,96 @@ Tres claves resultan de esta fase: una clave de servicio, una clave de publicado ``` | Instalar en Servidor de Gestión | Instalar en Switch | - |---------------------------------|-------------------| + |---------------------------------|--------------------| | CLI `doublezero` | Agente de Configuración | - | Tu par de claves de servicio | Agente de Telemetría | - | Tu par de claves de publicador de métricas | Par de claves de publicador de métricas (copia) | + | Su par de claves de servicio | Agente de Telemetría | + | Su par de claves del publicador de métricas | Par de claves del publicador de métricas (copia) | ### ¿Qué Son las Claves? -Piensa en las claves como credenciales de inicio de sesión seguras: +Piense en las claves como credenciales de inicio de sesión seguras: -- **Clave de Servicio**: Tu identidad como contribuidor - usada para ejecutar comandos del CLI -- **Clave de Publicador de Métricas**: La identidad de tu dispositivo para enviar datos de telemetría -- **Clave de Gestor de Recompensas**: Controla qué billeteras reciben tus recompensas - ver [Gestión de Recompensas](contribute-rewards.md) +- **Clave de Servicio**: Su identidad como contribuidor - utilizada para ejecutar comandos del CLI +- **Clave del Publicador de Métricas**: La identidad de su dispositivo para enviar datos de telemetría +- **Clave del Gestor de Recompensas**: Controla qué billeteras reciben sus recompensas - ver [Gestión de Recompensas](https://github.com/malbeclabs/contributors#rewards-management) en el repositorio de contribuidores -Las tres son pares de claves criptográficas (una clave pública que compartes, una clave privada que mantienes en secreto). +Las tres son pares de claves criptográficas (una clave pública que comparte, una clave privada que mantiene en secreto). ```mermaid flowchart LR - subgraph "Tus Claves" + subgraph "Sus Claves" SK[Clave de Servicio
~/.config/solana/id.json] - MK[Clave de Publicador de Métricas
~/.config/doublezero/metrics-publisher.json] - RK[Clave de Gestor de Recompensas
mantener fuera de línea] + MK[Clave del Publicador de Métricas
~/.config/doublezero/metrics-publisher.json] + RK[Clave del Gestor de Recompensas
mantener sin conexión] end - SK -->|Usada para| CLI[Comandos CLI
doublezero device create
doublezero link create] - MK -->|Usada para| TEL[Agente de Telemetría
Envía métricas en la cadena] - RK -->|Usada para| REW[Portal de Recompensas
Configura billeteras destinatarias] + SK -->|Usada para| CLI[Comandos del CLI
doublezero device create
doublezero link create] + MK -->|Usada para| TEL[Agente de Telemetría
Envía métricas on-chain] + RK -->|Usada para| REW[Portal de Recompensas
Establece billeteras destinatarias] ``` -!!! note "Mantén la clave de gestor de recompensas separada" - La clave de servicio y la clave de publicador de métricas residen en tu servidor de gestión y switch. La clave de gestor de recompensas controla hacia dónde va tu dinero, así que mantenla fuera de esas máquinas. Solo se necesita cuando cambias tus billeteras destinatarias. +!!! note "Mantenga la clave del gestor de recompensas separada" + La clave de servicio y la clave del publicador de métricas residen en su servidor de gestión y switch. La clave del gestor de recompensas controla a dónde va su dinero, así que manténgala fuera de esas máquinas. Solo se necesita cuando cambia sus billeteras destinatarias. -### Paso 2.1: Genera Tu Clave de Servicio +### Paso 2.1: Solicitar Acceso al Repositorio de Contribuidores -Esta es tu identidad principal para interactuar con DoubleZero. +Contacte a la Fundación DoubleZero o Malbec Labs y proporcióneles su **nombre de usuario de GitHub**. + +Le otorgarán acceso al repositorio privado [malbeclabs/contributors](https://github.com/malbeclabs/contributors). Haga esto primero: el repositorio contiene la configuración base del dispositivo, los perfiles TCAM y ACL, y las instrucciones de gestión de recompensas que necesita en los pasos siguientes. + +### Paso 2.2: Generar Su Clave de Servicio + +Esta es su identidad principal para interactuar con DoubleZero. ```bash doublezero keygen ``` -Esto crea un par de claves en la ubicación predeterminada. La salida muestra tu **clave pública** - esto es lo que compartirás con DZF. +Esto crea un par de claves en la ubicación predeterminada. La salida muestra su **clave pública** - esto es lo que compartirá con DZF. -### Paso 2.2: Genera Tu Clave de Publicador de Métricas +### Paso 2.3: Generar Su Clave del Publicador de Métricas -Esta clave es usada por el Agente de Telemetría para firmar los envíos de métricas. +Esta clave es utilizada por el Agente de Telemetría para firmar los envíos de métricas. ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Paso 2.3: Crea Tu Billetera de Gestor de Recompensas - -Esta es la tercera clave. Controla qué billeteras reciben tus recompensas, y nunca las retiene. - -Crea una billetera Solana que controles y con la que puedas firmar, luego fínanciala con aproximadamente 0.01 SOL para cubrir las tarifas de transacción. Una billetera de hardware es una buena opción. No reutilices tu clave de servicio. +### Paso 2.4: Enviar Su Clave de Servicio a DZF -Solo necesitas la billetera en este punto. Configurarás las billeteras que realmente reciben tus recompensas en el [Paso 2.7](#paso-27-configura-tus-destinatarios-de-recompensas), después de que DZF haya registrado esta clave. +Envíe a DZF su **clave pública de servicio**. -### Paso 2.4: Enviar Claves a DZF - -Contacta a la Fundación DoubleZero o Malbec Labs y proporciona: - -1. Tu **clave pública de servicio** -2. Tu **clave pública de gestor de recompensas** (del Paso 2.3) -3. Tu **nombre de usuario de GitHub** (para acceso al repositorio) - -Envía las tres juntas. DZF registra la clave de servicio y la clave de gestor de recompensas en transacciones separadas en la cadena, así que enviarlas al mismo tiempo ahorra un viaje de ida y vuelta. +Ellos crearán su **cuenta de contribuidor** on-chain y confirmarán cuando esté listo. !!! danger "Solo claves públicas" - Nunca envíes una clave privada o un archivo de par de claves a nadie, incluyendo DZF. DZF solo necesita tus claves públicas. - -Ellos: - -- Crearán tu **cuenta de contribuidor** en la cadena -- Registrarán tu **clave de gestor de recompensas** contra tu clave de servicio -- Otorgarán acceso al **repositorio privado de contribuidores** + Nunca envíe una clave privada o un archivo de par de claves a nadie, incluyendo a DZF. Solo la clave pública es necesaria. -### Paso 2.5: Verifica Tu Cuenta +### Paso 2.5: Verificar Su Cuenta -Una vez confirmado, verifica que tu cuenta de contribuidor existe: +Una vez confirmado, verifique que su cuenta de contribuidor existe: ```bash doublezero contributor list ``` -Deberías ver tu código de contribuidor en la lista. - -Verifica también que tu clave de gestor de recompensas fue registrada: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` - -La columna `manager` debería mostrar tu clave pública de gestor de recompensas. Si está vacía, pide a DZF que complete ese paso. - -### Paso 2.6: Accede al Repositorio de Contribuidores - -El repositorio [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contiene: - -- Configuraciones base de dispositivos -- Perfiles TCAM -- Configuraciones de ACL -- Instrucciones adicionales de configuración - -Sigue las instrucciones allí para la configuración específica del dispositivo. +Debería ver su código de contribuidor en la lista. -### Paso 2.7: Configura Tus Destinatarios de Recompensas +### Paso 2.6: Configurar la Gestión de Recompensas -Ahora indica qué billeteras reciben tus recompensas y en qué proporciones. Haz esto antes de que tu dispositivo comience a transportar tráfico. Las recompensas se acumulan desde el momento en que tus enlaces están activos, pero el protocolo no puede pagarlas hasta que hayas designado billeteras destinatarias. +La gestión de recompensas decide qué billeteras reciben los [2Z](glossary.md#2z-token) que genera su contribución, y en qué proporciones. -Inicia sesión en [doublezero.xyz/rewards](https://doublezero.xyz/rewards) con tu billetera de gestor de recompensas, selecciona tu clave de servicio, luego ingresa cada billetera destinataria y su porcentaje. Los porcentajes deben sumar 100. +Siga las instrucciones de [Gestión de Recompensas](https://github.com/malbeclabs/contributors#rewards-management) en el repositorio de contribuidores, al que ahora tiene acceso desde el Paso 2.1. -!!! warning "Cada destinatario necesita una cuenta de token 2Z" - El protocolo envía 2Z con una transferencia de token simple y no crea la cuenta de token por ti. Una billetera destinataria sin cuenta de token 2Z causa que el pago de esa época falle. - -Consulta [Gestión de Recompensas](contribute-rewards.md) para el tutorial completo, incluyendo la alternativa por CLI, cómo verificar la cuenta de token y cómo verificar el resultado. +!!! note "Esto no bloquea el resto de su configuración" + Puede aprovisionar su dispositivo, establecer enlaces y comenzar a transportar tráfico sin tener esto en su lugar, así que trate las fases siguientes como independientes de esto. --- ## Fase 3: Aprovisionamiento del Dispositivo -Ahora registrarás tu dispositivo físico en la blockchain y configurarás sus interfaces. +Ahora registrará su dispositivo físico en la blockchain y configurará sus interfaces. -### Entendiendo los Tipos de Dispositivo +### Comprender los Tipos de Dispositivo **Edge** — acepta solo conexiones de usuarios @@ -327,7 +293,7 @@ flowchart LR E_CYOA --- E_TUN end EU["Usuarios"] -.|Túnel GRE|.-> E_CYOA - E_DZX <-->|Enlace DZX| ED["DZD (contribuidor diferente)"] + E_DZX <-->|Enlace DZX| ED["DZD (diferente contribuidor)"] ``` **Transit** — mueve tráfico entre dispositivos, sin conexiones de usuarios @@ -339,7 +305,7 @@ flowchart LR T_DZX["Interfaz de enlace DZX"] end T_WAN <-->|Enlace WAN| T2["DZD (mismo contribuidor)"] - T_DZX <-->|Enlace DZX| TD["DZD (contribuidor diferente)"] + T_DZX <-->|Enlace DZX| TD["DZD (diferente contribuidor)"] ``` **Hybrid** — conexiones de usuarios y backbone, el más común @@ -356,18 +322,18 @@ flowchart LR end HU["Usuarios"] -.|Túnel GRE|.-> H_CYOA H_WAN <-->|Enlace WAN| H2["DZD (mismo contribuidor)"] - H_DZX <-->|Enlace DZX| HD["DZD (contribuidor diferente)"] + H_DZX <-->|Enlace DZX| HD["DZD (diferente contribuidor)"] ``` | Tipo | Qué Hace | Cuándo Usarlo | |------|----------|---------------| -| **Edge** | Acepta solo conexiones de usuarios | Ubicación única, solo orientado a usuarios | +| **Edge** | Acepta solo conexiones de usuarios | Ubicación única, solo orientado al usuario | | **Transit** | Mueve tráfico entre dispositivos | Conectividad backbone, sin usuarios | -| **Hybrid** | Conexiones de usuarios Y backbone | El más común - hace todo | +| **Hybrid** | Tanto conexiones de usuarios COMO backbone | Más común - hace todo | -### Paso 3.1: Encuentra Tu Ubicación e Intercambio +### Paso 3.1: Encontrar Su Ubicación e Intercambio -Antes de crear tu dispositivo, busca los códigos de la ubicación de tu centro de datos y el intercambio más cercano: +Antes de crear su dispositivo, busque los códigos de la ubicación de su centro de datos y el intercambio más cercano: ```bash # Listar ubicaciones disponibles (centros de datos) @@ -377,19 +343,19 @@ doublezero location list doublezero exchange list ``` -### Paso 3.2: Crea Tu Dispositivo en la Cadena +### Paso 3.2: Crear Su Dispositivo On-chain -Registra tu dispositivo en la blockchain: +Registre su dispositivo en la blockchain: ```bash doublezero device create \ - --code \ - --contributor \ + --code \ + --contributor \ --device-type hybrid \ --location \ --exchange \ --public-ip \ - --dz-prefixes + --dz-prefixes ``` **Ejemplo:** @@ -411,7 +377,7 @@ doublezero device create \ Signature: 4vKz8H...truncated...7xPq2 ``` -Verifica que tu dispositivo fue creado: +Verifique que su dispositivo fue creado: ```bash doublezero device list | grep nyc-dz001 @@ -421,15 +387,15 @@ doublezero device list | grep nyc-dz001 | Parámetro | Qué Significa | |-----------|---------------| -| `--code` | Un nombre único para tu dispositivo (p. ej., `nyc-dz001`) | -| `--contributor` | Tu código de contribuidor (proporcionado por DZF) | -| `--device-type` | `hybrid`, `transit`, o `edge` | +| `--code` | Un nombre único para su dispositivo (p. ej., `nyc-dz001`) | +| `--contributor` | Su código de contribuidor (proporcionado por DZF) | +| `--device-type` | `hybrid`, `transit` o `edge` | | `--location` | Código del centro de datos de `location list` | | `--exchange` | Código del intercambio más cercano de `exchange list` | -| `--public-ip` | La IP pública donde los usuarios se conectan a tu dispositivo por internet | -| `--dz-prefixes` | Tu bloque de IP asignado para usuarios | +| `--public-ip` | La IP pública donde los usuarios se conectan a su dispositivo por internet | +| `--dz-prefixes` | Su bloque de IPs asignado para usuarios | -### Paso 3.3: Crea las Interfaces Loopback Requeridas +### Paso 3.3: Crear Interfaces Loopback Requeridas Cada dispositivo necesita dos interfaces loopback para enrutamiento interno: @@ -447,9 +413,9 @@ doublezero device interface create Loopback256 --loopback- Signature: 3mNx9K...truncated...8wRt5 ``` -### Paso 3.4: Crea Interfaces Físicas +### Paso 3.4: Crear Interfaces Físicas -Registra las interfaces físicas que se usarán para enlaces WAN o DZX. Estas interfaces deben existir en la cadena antes de que puedas crear un enlace que las referencie. En este paso solo registras la interfaz y su ancho de banda, el enlace se crea en un paso posterior. +Registre las interfaces físicas que se utilizarán para enlaces WAN o DZX. Estas interfaces deben existir on-chain antes de que pueda crear un enlace que las referencie. En este paso solo registra la interfaz y su ancho de banda; el enlace se crea en un paso posterior. ```bash doublezero device interface create \ @@ -469,22 +435,22 @@ doublezero device interface create nyc-dz001 Ethernet1/1 \ Signature: 7pQw2R...truncated...4xKm9 ``` -Repite esto para cada interfaz que se usará como endpoint de un enlace WAN o DZX. Las interfaces CYOA y DIA se registran por separado en el siguiente paso. +Repita esto para cada interfaz que se utilizará como punto final de un enlace WAN o DZX. Las interfaces CYOA y DIA se registran por separado en el siguiente paso. -### Paso 3.5: Crea la Interfaz CYOA (para dispositivos Edge/Hybrid) +### Paso 3.5: Crear Interfaz CYOA (para dispositivos Edge/Hybrid) -Los DZDs hybrid y edge necesitan **dos direcciones IP públicas** en las que los usuarios terminan sus túneles GRE. Los usuarios pueden conectarse por unicast, multicast, o ambos, y qué IP sirve para qué propósito rota por usuario. +Los DZDs hybrid y edge necesitan **dos direcciones IP públicas** donde los usuarios terminan sus túneles GRE. Los usuarios pueden conectarse por unicast, multicast o ambos, y qué IP sirve para qué propósito rota por usuario. -Ambas IPs deben registrarse con `--user-tunnel-endpoint true`, ya sea en una interfaz física o un loopback. Esto incluye la IP que proporcionaste al crear el dispositivo, esa IP aún necesita registrarse explícitamente aquí. +Ambas IPs deben registrarse con `--user-tunnel-endpoint true`, ya sea en una interfaz física o en un loopback. Esto incluye la IP que proporcionó en el momento de la creación del dispositivo; esa IP aún necesita ser registrada explícitamente aquí. -Si tienes restricciones de IP, puedes usar el primer `/32` de tu prefijo DZ como una de las dos IPs. +Si tiene restricciones de IP, puede usar el primer `/32` de su prefijo DZ como una de las dos IPs. #### CYOA y DIA | Tipo | Bandera | Propósito | |------|---------|-----------| | DIA | `--interface-dia dia` | Marca el puerto como acceso directo a internet | -| CYOA | `--interface-cyoa ` | Declara cómo los usuarios conectan túneles GRE a tu dispositivo | +| CYOA | `--interface-cyoa ` | Declara cómo los usuarios conectan túneles GRE a su dispositivo | La bandera CYOA siempre se establece en una **interfaz física** (puerto Ethernet o canal de puertos). Nunca en un loopback. @@ -492,8 +458,8 @@ La bandera CYOA siempre se establece en una **interfaz física** (puerto Etherne |--------------|---------------| | `gre-over-dia` | Los usuarios se conectan por internet público. El más común. | | `gre-over-private-peering` | Los usuarios se conectan mediante una conexión cruzada directa o circuito privado | -| `gre-over-public-peering` | Los usuarios hacen peering contigo en un Internet Exchange (IX) | -| `gre-over-fabric` | Los usuarios están co-ubicados y se conectan por un fabric local | +| `gre-over-public-peering` | Los usuarios hacen peering con usted en un Internet Exchange (IX) | +| `gre-over-fabric` | Los usuarios están co-ubicados y se conectan a través de un fabric local | | `gre-over-cable` | Conexión directa por cable a un único usuario dedicado | #### Escenario A: Interfaz física única @@ -524,9 +490,9 @@ flowchart LR | Interfaz | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| | Ethernet1/1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad del puerto | tasa comprometida | `bgp` o `static` | `true` | -| Loopback100 | — | — | tu /32 público | `0bps` | — | — | `true` | +| Loopback100 | — | — | su /32 público | `0bps` | — | — | `true` | -Ejemplo de comandos a ejecutar basados en el Escenario A: +Ejemplo de comandos a ejecutar basándose en el Escenario A: ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -574,9 +540,9 @@ flowchart LR | Interfaz | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| | Port-Channel1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad combinada del LAG | tasa comprometida | `bgp` o `static` | `true` | -| Loopback100 | — | — | tu /32 público | `0bps` | — | — | `true` | +| Loopback100 | — | — | su /32 público | `0bps` | — | — | `true` | -Ejemplo de comandos a ejecutar basados en el Escenario B: +Ejemplo de comandos a ejecutar basándose en el Escenario B: ```bash doublezero device interface create mydzd-fra01 Port-Channel1 \ --interface-cyoa gre-over-dia \ @@ -596,4 +562,43 @@ doublezero device interface create mydzd-fra01 Loopback100 \ #### Escenario C: Enlaces ascendentes físicos duales a routers separados -Cada \ No newline at end of file +Cada interfaz física se conecta a un router upstream diferente. Las dos IPs públicas residen en Loopback100 y Loopback101, ambos registrados como endpoints de túnel de usuario. + +```mermaid +flowchart LR + USERS(["Usuarios Finales"]) + + RA["Router A + 203.0.113.2/30"] + RB["Router B + 203.0.113.6/30"] + + subgraph DZD["DZD"] + E1["Eth1/1 + 203.0.113.1/30 + CYOA · DIA"] + E2["Eth2/1 + 203.0.113.5/30 + CYOA · DIA"] + LO0["Loopback100 + 198.51.100.1/32\n endpoint de túnel de usuario"] + LO1["Loopback101 + 198.51.100.2/32\n endpoint de túnel de usuario"] + E1 --> LO0 + E2 --> LO1 + end + + RA -- "10GbE" --- E1 + RB -- "10GbE" --- E2 + USERS -. "Túneles GRE" .-> LO0 + USERS -. "Túneles GRE" .-> LO1 +``` + +| Interfaz | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | +|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad del puerto | tasa comprometida | `bgp` o `static` | — | +| Ethernet2/1 | `gre-over-dia` | `dia` | IP/subred asignada por el contribuidor | velocidad del puerto | tasa comprometida | `bgp` o `static` | — | +| Loopback100 | — | — | su /32 público | `0bps` | — | — | `true` | +| Loopback101 | — | — | su /32 público | `0bps` | — | — | `true` | + +Ejemplo de comandos a ejecutar basándose en el Esc \ No newline at end of file diff --git a/docs/contribute-provisioning.fr.md b/docs/contribute-provisioning.fr.md index 24ecafe..92e0679 100644 --- a/docs/contribute-provisioning.fr.md +++ b/docs/contribute-provisioning.fr.md @@ -1,46 +1,46 @@ --- -description: Guide étape par étape pour provisionner un DoubleZero Device (DZD) et enregistrer ses interfaces et rôles on-chain. +description: Guide étape par étape pour provisionner un appareil DoubleZero (DZD) et enregistrer ses interfaces et rôles on-chain. --- -# Guide de provisionnement d'un appareil +# Guide de provisionnement d'appareil -Ce guide vous accompagne dans le provisionnement d'un DoubleZero Device (DZD) du début à la fin. Chaque phase correspond à la [Liste de contrôle d'intégration](contribute-overview.md#onboarding-checklist). +Ce guide vous accompagne dans le provisionnement d'un appareil DoubleZero (DZD) du début à la fin. Chaque phase correspond à la [Liste de contrôle d'intégration](contribute-overview.md#onboarding-checklist). --- ## Comment tout s'articule -Ce guide vous accompagne dans l'enregistrement de votre infrastructure on-chain afin que le réseau DoubleZero puisse acheminer le trafic à travers celle-ci. Plus votre appareil est complètement enregistré, plus il est utile au réseau. Une représentation on-chain complète de votre appareil permet un meilleur dépannage, une meilleure planification de la capacité, et permet au contrôleur de prendre des décisions éclairées. À terme, l'objectif est que le contrôleur prenne en charge une part croissante de la responsabilité de configuration. +Ce guide vous accompagne dans l'enregistrement de votre infrastructure on-chain afin que le réseau DoubleZero puisse acheminer le trafic à travers celle-ci. Plus votre appareil est complètement enregistré, plus il est utile au réseau. Une représentation on-chain complète de votre appareil permet un meilleur diagnostic, une meilleure planification de capacité et permet au contrôleur de prendre des décisions éclairées. À terme, l'objectif est que le contrôleur prenne en charge une part croissante de la responsabilité de configuration. ### Concepts clés **Interfaces** -Les interfaces d'un DZD se présentent sous différentes formes : ports Ethernet, port channels (LAGs composés de plusieurs ports Ethernet) et loopbacks. Chaque interface qui joue un rôle dans le réseau doit être enregistrée on-chain avec les indicateurs appropriés afin que le protocole sache à quoi elle sert. +Les interfaces d'un DZD se présentent sous différentes formes : ports Ethernet, port channels (LAGs composés de plusieurs ports Ethernet) et loopbacks. Chaque interface jouant un rôle dans le réseau doit être enregistrée on-chain avec les indicateurs appropriés afin que le protocole sache ce qu'elle fait. Les ports Ethernet et les port channels peuvent remplir les rôles suivants : -| Indicateur | Signification | +| Indicateur | Ce qu'il signifie | |------|---------------| -| `--interface-dia dia` | Marque l'interface comme liaison montante d'accès internet direct | -| `--interface-cyoa ` | Déclare comment les utilisateurs établissent des tunnels GRE via cette interface (ex. via l'internet public, via un lien de peering privé) | -| `--user-tunnel-endpoint true` | Cette interface porte une IP publique sur laquelle les utilisateurs terminent les tunnels GRE | +| `--interface-dia dia` | Marque l'interface comme lien montant d'accès internet direct | +| `--interface-cyoa ` | Déclare comment les utilisateurs établissent des tunnels GRE via cette interface (par ex. via l'internet public, via un lien de peering privé) | +| `--user-tunnel-endpoint true` | Cette interface porte une IP publique sur laquelle les utilisateurs terminent leurs tunnels GRE | -Les interfaces utilisées pour les liens WAN ou DZX ne portent pas d'indicateur spécifique ; elles sont enregistrées avec leur bande passante puis référencées lors de la création du lien. +Les interfaces utilisées pour les liens WAN ou DZX ne portent pas d'indicateur spécifique, elles sont enregistrées avec leur bande passante puis référencées lors de la création du lien. -Les interfaces loopback servent à plusieurs fins : +Les interfaces loopback servent plusieurs objectifs : -| Loopback | Signification | +| Loopback | Ce qu'il signifie | |----------|---------------| -| **Loopback100 / 101** | Portent des IP publiques sur lesquelles les utilisateurs terminent les tunnels GRE. Enregistrées avec `--user-tunnel-endpoint true`. | -| **Loopback255** (`vpnv4`) | Enregistrée pour que le contrôleur puisse assigner une IP utilisée pour l'identifiant de routeur BGP, le peering VPN-IPv4 (unicast), l'identité IS-IS et le segment routing | -| **Loopback256** (`ipv4`) | Enregistrée pour que le contrôleur puisse assigner une IP utilisée pour le peering BGP IPv4 (multicast) et les sessions MSDP | +| **Loopback100 / 101** | Portent des IP publiques sur lesquelles les utilisateurs terminent leurs tunnels GRE. Enregistrées avec `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Enregistrée pour que le contrôleur puisse attribuer une IP utilisée pour l'identifiant de routeur BGP, le peering VPN-IPv4 (unicast), l'identité IS-IS et le segment routing | +| **Loopback256** (`ipv4`) | Enregistrée pour que le contrôleur puisse attribuer une IP utilisée pour le peering BGP IPv4 (multicast) et les sessions MSDP | **Liens** Les liens sont enregistrés séparément des interfaces, et les interfaces doivent exister on-chain avant qu'un lien puisse les référencer. Lorsque vous créez un lien WAN ou DZX, vous spécifiez une interface déjà enregistrée comme point de terminaison physique du lien. Toutes les interfaces ne sont pas liées à un lien : les interfaces DIA, CYOA et loopback ne sont pas connectées à un lien. -| Terme | Signification | +| Terme | Ce qu'il signifie | |------|---------------| | **Lien WAN** | Un lien entre deux de vos propres DZD | | **Lien DZX** | Un lien entre votre DZD et le DZD d'un autre contributeur | @@ -54,44 +54,44 @@ flowchart TB end subgraph Your Infrastructure - MGMT[Serveur de gestion
DoubleZero CLI] - subgraph DZD[Votre DZD] - CYOA["Interface DIA · CYOA
(liaison montante utilisateur)"] - WAN_INTF["Interface lien WAN"] - DZX_INTF["Interface lien DZX"] - LO100["Loopback100/101
(point de terminaison tunnel utilisateur)"] + MGMT[Management Server
DoubleZero CLI] + subgraph DZD[Your DZD] + CYOA["DIA · CYOA interface
(user-facing uplink)"] + WAN_INTF["WAN link interface"] + DZX_INTF["DZX link interface"] + LO100["Loopback100/101
(user tunnel endpoint)"] end - DZD2[Votre autre DZD] + DZD2[Your other DZD] end subgraph Other Contributor - OtherDZD[Leur DZD] + OtherDZD[Their DZD] end - USERS["Utilisateurs"] + USERS["Users"] - MGMT -.->|Enregistre appareils,
liens, interfaces| SC - WAN_INTF ---|Lien WAN| DZD2 - DZX_INTF ---|Lien DZX| OtherDZD - USERS -.|Tunnel GRE|.-> CYOA - CYOA ---|route vers| LO100 + MGMT -.->|Registers devices,
links, interfaces| SC + WAN_INTF ---|WAN Link| DZD2 + DZX_INTF ---|DZX Link| OtherDZD + USERS -.|GRE tunnel|.-> CYOA + CYOA ---|routes to| LO100 ``` --- ## Phase 1 : Prérequis -Avant de pouvoir provisionner un appareil, vous devez avoir le matériel physique installé et certaines adresses IP allouées. +Avant de pouvoir provisionner un appareil, vous devez avoir le matériel physique installé et quelques adresses IP allouées. ### Ce dont vous avez besoin | Exigence | Pourquoi c'est nécessaire | |-------------|-----------------| -| **Matériel DZD** | Switch Arista 7280CR3A (voir les [spécifications matérielles](contribute.md#hardware-requirements)) | -| **Espace rack** | 1U par DZD, avec un flux d'air adéquat. Voir [Rack et alimentation](contribute.md#rack-power-requirements) | +| **Matériel DZD** | Switch Arista 7280CR3A (voir [spécifications matérielles](contribute.md#hardware-requirements)) | +| **Espace rack** | 2U réservés par DZD (1U utilisé aujourd'hui), avec une ventilation appropriée. Voir [Rack et alimentation](contribute.md#rack-power-requirements) | | **Alimentation** | Deux alimentations indépendantes, chacune capable de supporter la charge totale seule. Voir [Rack et alimentation](contribute.md#rack-power-requirements) | | **Accès de gestion** | Accès SSH/console pour configurer le switch | -| **Connectivité internet** | Pour la publication des métriques et la récupération de la configuration depuis le contrôleur | +| **Connectivité Internet** | Pour la publication de métriques et la récupération de configuration depuis le contrôleur | | **Bloc IPv4 public** | Minimum /29 pour le pool de préfixes DZ (voir ci-dessous) | ### Installer le CLI DoubleZero @@ -121,25 +121,25 @@ Votre préfixe DZ est un bloc d'adresses IP publiques que le protocole DoubleZer ```mermaid flowchart LR - subgraph "Votre bloc /29 (8 IPs)" - IP1["Première IP
Réservée pour
votre appareil"] + subgraph "Your /29 Block (8 IPs)" + IP1["First IP
Reserved for
your device"] IP2["IP 2"] IP3["IP 3"] IP4["..."] IP8["IP 8"] end - IP1 -->|Assignée à| LO[Loopback100
sur votre DZD] - IP2 -->|Allouée à| U1[Utilisateur 1] - IP3 -->|Allouée à| U2[Utilisateur 2] + IP1 -->|Assigned to| LO[Loopback100
on your DZD] + IP2 -->|Allocated to| U1[User 1] + IP3 -->|Allocated to| U2[User 2] ``` **Comment les préfixes DZ sont utilisés :** -- **Première IP** : Réservée pour votre appareil (assignée à l'interface Loopback100) +- **Première IP** : Réservée à votre appareil (attribuée à l'interface Loopback100) - **IP restantes** : Allouées à des types d'utilisateurs spécifiques se connectant à votre DZD : - Utilisateurs `IBRLWithAllocatedIP` - - Utilisateurs `EdgeFiltering` (cas d'utilisation futur) + - Utilisateurs `EdgeFiltering` (cas d'usage futur) - **Utilisateurs IBRL** : Ne consomment PAS de ce pool (ils utilisent leur propre IP publique) !!! warning "Règles des préfixes DZ" @@ -153,8 +153,8 @@ flowchart LR **Exigences :** - Doivent être des adresses IPv4 **routables globalement (publiques)** - - Les plages IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le smart contract - - **Taille minimale : /29** (8 adresses), les préfixes plus grands sont préférés (ex. /28, /27) + - Les plages d'IP privées (10.x, 172.16-31.x, 192.168.x) sont rejetées par le smart contract + - **Taille minimale : /29** (8 adresses), des préfixes plus grands sont préférables (par ex. /28, /27) - Le bloc entier doit être disponible — ne pré-allouez aucune adresse Si vous avez besoin d'adresses pour votre propre équipement (IP d'interface DIA, gestion, etc.), utilisez un **pool d'adresses séparé**. @@ -163,9 +163,9 @@ flowchart LR ## Phase 2 : Configuration du compte -Dans cette phase, vous créez les clés cryptographiques qui vous identifient, vous et vos appareils, sur le réseau, et vous indiquez où vos récompenses doivent être versées. +Dans cette phase, vous créez les clés cryptographiques qui vous identifient, vous et vos appareils, sur le réseau, et vous configurez la gestion des récompenses. -Trois clés résultent de cette phase : une clé de service, une clé de publication de métriques et une clé de gestionnaire de récompenses. Soumettez les clés publiques des trois à la DZF ensemble à l'[Étape 2.4](#etape-24-soumettre-les-cles-a-la-dzf). [Gestion des récompenses](contribute-rewards.md) couvre le volet récompenses dans son intégralité. +Les étapes s'exécutent dans cet ordre pour une raison : d'abord l'accès au dépôt, car celui-ci contient les instructions pour les étapes suivantes, puis vos clés, puis les récompenses. Certaines étapes nécessitent que DZF agisse avant que vous puissiez continuer, et chacune ci-dessous le précise. ### Où exécuter le CLI @@ -174,54 +174,60 @@ Trois clés résultent de cette phase : une clé de service, une clé de publica ```mermaid flowchart LR - subgraph "Serveur de gestion/VM" + subgraph "Management Server/VM" CLI[DoubleZero CLI] - KEYS[Vos paires de clés] + KEYS[Your Keypairs] end - subgraph "Votre switch DZD" + subgraph "Your DZD Switch" CA[Config Agent] TA[Telemetry Agent] end - CLI -->|Crée appareils, liens| BC[Blockchain] - CA -->|Récupère la config| CTRL[Contrôleur] - TA -->|Soumet les métriques| BC + CLI -->|Creates devices, links| BC[Blockchain] + CA -->|Pulls config| CTRL[Controller] + TA -->|Submits metrics| BC ``` | Installer sur le serveur de gestion | Installer sur le switch | |-----------------------------|-------------------| | CLI `doublezero` | Config Agent | | Votre paire de clés de service | Telemetry Agent | - | Votre paire de clés de publication de métriques | Paire de clés de publication de métriques (copie) | + | Votre paire de clés du publieur de métriques | Paire de clés du publieur de métriques (copie) | ### Que sont les clés ? -Pensez aux clés comme des identifiants de connexion sécurisés : +Considérez les clés comme des identifiants de connexion sécurisés : - **Clé de service** : Votre identité de contributeur — utilisée pour exécuter les commandes CLI -- **Clé de publication de métriques** : L'identité de votre appareil pour soumettre les données de télémétrie -- **Clé de gestionnaire de récompenses** : Contrôle quels portefeuilles reçoivent vos récompenses — voir [Gestion des récompenses](contribute-rewards.md) +- **Clé du publieur de métriques** : L'identité de votre appareil pour soumettre les données de télémétrie +- **Clé du gestionnaire de récompenses** : Contrôle quels portefeuilles reçoivent vos récompenses — voir [Gestion des récompenses](https://github.com/malbeclabs/contributors#rewards-management) dans le dépôt des contributeurs Les trois sont des paires de clés cryptographiques (une clé publique que vous partagez, une clé privée que vous gardez secrète). ```mermaid flowchart LR - subgraph "Vos clés" - SK[Clé de service
~/.config/solana/id.json] - MK[Clé de publication de métriques
~/.config/doublezero/metrics-publisher.json] - RK[Clé de gestionnaire de récompenses
conserver hors ligne] + subgraph "Your Keys" + SK[Service Key
~/.config/solana/id.json] + MK[Metrics Publisher Key
~/.config/doublezero/metrics-publisher.json] + RK[Rewards Manager Key
keep offline] end - SK -->|Utilisée pour| CLI[Commandes CLI
doublezero device create
doublezero link create] - MK -->|Utilisée pour| TEL[Telemetry Agent
Soumet les métriques on-chain] - RK -->|Utilisée pour| REW[Portail de récompenses
Définit les portefeuilles destinataires] + SK -->|Used for| CLI[CLI Commands
doublezero device create
doublezero link create] + MK -->|Used for| TEL[Telemetry Agent
Submits metrics onchain] + RK -->|Used for| REW[Rewards Portal
Sets recipient wallets] ``` -!!! note "Gardez la clé de gestionnaire de récompenses séparée" - La clé de service et la clé de publication de métriques se trouvent sur votre serveur de gestion et votre switch. La clé de gestionnaire de récompenses contrôle où va votre argent, alors gardez-la hors de ces machines. Elle n'est nécessaire que lorsque vous modifiez vos portefeuilles destinataires. +!!! note "Gardez la clé du gestionnaire de récompenses séparée" + La clé de service et la clé du publieur de métriques résident sur votre serveur de gestion et votre switch. La clé du gestionnaire de récompenses contrôle où va votre argent, donc gardez-la hors de ces machines. Elle n'est nécessaire que lorsque vous modifiez vos portefeuilles destinataires. -### Étape 2.1 : Générer votre clé de service +### Étape 2.1 : Demander l'accès au dépôt des contributeurs + +Contactez la DoubleZero Foundation ou Malbec Labs et fournissez-leur votre **nom d'utilisateur GitHub**. + +Ils vous accordent l'accès au dépôt privé [malbeclabs/contributors](https://github.com/malbeclabs/contributors). Faites-le en premier : le dépôt contient la configuration de base des appareils, les profils TCAM et ACL, et les instructions de gestion des récompenses dont vous avez besoin dans les étapes suivantes. + +### Étape 2.2 : Générer votre clé de service C'est votre identité principale pour interagir avec DoubleZero. @@ -229,9 +235,9 @@ C'est votre identité principale pour interagir avec DoubleZero. doublezero keygen ``` -Cela crée une paire de clés à l'emplacement par défaut. La sortie affiche votre **clé publique** — c'est ce que vous partagerez avec la DZF. +Cela crée une paire de clés à l'emplacement par défaut. La sortie affiche votre **clé publique** — c'est ce que vous partagerez avec DZF. -### Étape 2.2 : Générer votre clé de publication de métriques +### Étape 2.3 : Générer votre clé de publieur de métriques Cette clé est utilisée par le Telemetry Agent pour signer les soumissions de métriques. @@ -239,32 +245,14 @@ Cette clé est utilisée par le Telemetry Agent pour signer les soumissions de m doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Étape 2.3 : Créer votre portefeuille de gestionnaire de récompenses - -C'est la troisième clé. Elle contrôle quels portefeuilles reçoivent vos récompenses, et ne les détient jamais elle-même. - -Créez un portefeuille Solana que vous contrôlez et avec lequel vous pouvez signer, puis approvisionnez-le d'environ 0,01 SOL pour couvrir les frais de transaction. Un portefeuille matériel est un bon choix. Ne réutilisez pas votre clé de service. - -Vous n'avez besoin du portefeuille qu'à ce stade. Vous définirez les portefeuilles qui reçoivent effectivement vos récompenses à l'[Étape 2.7](#etape-27-definir-vos-destinataires-de-recompenses), après que la DZF a enregistré cette clé. - -### Étape 2.4 : Soumettre les clés à la DZF +### Étape 2.4 : Soumettre votre clé de service à DZF -Contactez la DoubleZero Foundation ou Malbec Labs et fournissez : +Envoyez à DZF votre **clé publique de service**. -1. Votre **clé publique de service** -2. Votre **clé publique de gestionnaire de récompenses** (de l'Étape 2.3) -3. Votre **nom d'utilisateur GitHub** (pour l'accès au dépôt) - -Envoyez les trois ensemble. La DZF enregistre la clé de service et la clé de gestionnaire de récompenses dans des transactions on-chain séparées, donc les envoyer en même temps évite un aller-retour. +Ils créent votre **compte contributeur** on-chain et confirment lorsque c'est fait. !!! danger "Clés publiques uniquement" - N'envoyez jamais une clé privée ou un fichier de paire de clés à qui que ce soit, y compris à la DZF. La DZF n'a jamais besoin que de vos clés publiques. - -Ils vont : - -- Créer votre **compte contributeur** on-chain -- Enregistrer votre **clé de gestionnaire de récompenses** associée à votre clé de service -- Accorder l'accès au **dépôt privé des contributeurs** + N'envoyez jamais une clé privée ou un fichier de paire de clés à quiconque, y compris DZF. Seule la clé publique est nécessaire. ### Étape 2.5 : Vérifier votre compte @@ -276,36 +264,14 @@ doublezero contributor list Vous devriez voir votre code contributeur dans la liste. -Vérifiez également que votre clé de gestionnaire de récompenses a été enregistrée : - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` - -La colonne `manager` devrait afficher votre clé publique de gestionnaire de récompenses. Si elle est vide, demandez à la DZF de compléter cette étape. - -### Étape 2.6 : Accéder au dépôt des contributeurs - -Le dépôt [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contient : - -- Les configurations de base des appareils -- Les profils TCAM -- Les configurations ACL -- Des instructions de configuration supplémentaires - -Suivez les instructions qui s'y trouvent pour la configuration spécifique à votre appareil. - -### Étape 2.7 : Définir vos destinataires de récompenses - -Indiquez maintenant quels portefeuilles reçoivent vos récompenses, et dans quelles proportions. Faites-le avant que votre appareil ne commence à acheminer du trafic. Les récompenses s'accumulent dès que vos liens sont actifs, mais le protocole ne peut pas les verser tant que vous n'avez pas désigné de portefeuilles destinataires. +### Étape 2.6 : Configurer la gestion des récompenses -Connectez-vous à [doublezero.xyz/rewards](https://doublezero.xyz/rewards) avec votre portefeuille de gestionnaire de récompenses, sélectionnez votre clé de service, puis saisissez chaque portefeuille destinataire et son pourcentage. Les pourcentages doivent totaliser 100. +La gestion des récompenses détermine quels portefeuilles reçoivent les [2Z](glossary.md#2z-token) que votre contribution génère, et dans quelles proportions. -!!! warning "Chaque destinataire a besoin d'un compte de jetons 2Z" - Le protocole envoie les 2Z avec un transfert de jetons simple et ne crée pas le compte de jetons pour vous. Un portefeuille destinataire sans compte de jetons 2Z entraîne l'échec du versement de cette époque. +Suivez [Gestion des récompenses](https://github.com/malbeclabs/contributors#rewards-management) dans le dépôt des contributeurs, auquel vous avez désormais accès depuis l'étape 2.1. -Voir [Gestion des récompenses](contribute-rewards.md) pour le guide complet, y compris l'alternative CLI, comment vérifier le compte de jetons et comment vérifier le résultat. +!!! note "Cela ne bloque pas le reste de votre configuration" + Vous pouvez provisionner votre appareil, établir des liens et commencer à acheminer du trafic sans que cela soit en place, donc traitez les phases ci-dessous comme indépendantes de celle-ci. --- @@ -315,65 +281,65 @@ Vous allez maintenant enregistrer votre appareil physique sur la blockchain et c ### Comprendre les types d'appareils -**Edge** — accepte uniquement les connexions utilisateur +**Edge** — accepte uniquement les connexions utilisateurs ```mermaid flowchart LR - subgraph EDZD[DZD Edge] - E_CYOA["Interface DIA · CYOA"] + subgraph EDZD[Edge DZD] + E_CYOA["DIA · CYOA interface"] E_TUN["Loopback100/101 - (point de terminaison tunnel utilisateur)"] - E_DZX["Interface lien DZX"] + (user tunnel endpoint)"] + E_DZX["DZX link interface"] E_CYOA --- E_TUN end - EU["Utilisateurs"] -.|Tunnel GRE|.-> E_CYOA - E_DZX <-->|Lien DZX| ED["DZD (contributeur différent)"] + EU["Users"] -.|GRE tunnel|.-> E_CYOA + E_DZX <-->|DZX Link| ED["DZD (different contributor)"] ``` -**Transit** — achemine le trafic entre appareils, pas de connexions utilisateur +**Transit** — achemine le trafic entre appareils, pas de connexions utilisateurs ```mermaid flowchart LR - subgraph TDZD[DZD Transit] - T_WAN["Interface lien WAN"] - T_DZX["Interface lien DZX"] + subgraph TDZD[Transit DZD] + T_WAN["WAN link interface"] + T_DZX["DZX link interface"] end - T_WAN <-->|Lien WAN| T2["DZD (même contributeur)"] - T_DZX <-->|Lien DZX| TD["DZD (contributeur différent)"] + T_WAN <-->|WAN Link| T2["DZD (same contributor)"] + T_DZX <-->|DZX Link| TD["DZD (different contributor)"] ``` -**Hybride** — connexions utilisateur et backbone, le plus courant +**Hybride** — connexions utilisateurs et backbone, le plus courant ```mermaid flowchart LR - subgraph HDZD[DZD Hybride] - H_CYOA["Interface DIA · CYOA"] + subgraph HDZD[Hybrid DZD] + H_CYOA["DIA · CYOA interface"] H_TUN["Loopback100/101 - (point de terminaison tunnel utilisateur)"] - H_WAN["Interface lien WAN"] - H_DZX["Interface lien DZX"] + (user tunnel endpoint)"] + H_WAN["WAN link interface"] + H_DZX["DZX link interface"] H_CYOA --- H_TUN end - HU["Utilisateurs"] -.|Tunnel GRE|.-> H_CYOA - H_WAN <-->|Lien WAN| H2["DZD (même contributeur)"] - H_DZX <-->|Lien DZX| HD["DZD (contributeur différent)"] + HU["Users"] -.|GRE tunnel|.-> H_CYOA + H_WAN <-->|WAN Link| H2["DZD (same contributor)"] + H_DZX <-->|DZX Link| HD["DZD (different contributor)"] ``` | Type | Ce qu'il fait | Quand l'utiliser | |------|--------------|-------------| -| **Edge** | Accepte uniquement les connexions utilisateur | Emplacement unique, orienté utilisateur uniquement | +| **Edge** | Accepte uniquement les connexions utilisateurs | Emplacement unique, orienté utilisateur uniquement | | **Transit** | Achemine le trafic entre appareils | Connectivité backbone, pas d'utilisateurs | -| **Hybride** | Connexions utilisateur ET backbone | Le plus courant — fait tout | +| **Hybride** | Connexions utilisateurs ET backbone | Le plus courant — fait tout | -### Étape 3.1 : Trouver votre emplacement et votre point d'échange +### Étape 3.1 : Trouver votre emplacement et échange -Avant de créer votre appareil, recherchez les codes de votre emplacement de data center et du point d'échange le plus proche : +Avant de créer votre appareil, recherchez les codes de votre emplacement de centre de données et de l'échange le plus proche : ```bash -# Lister les emplacements disponibles (data centers) +# List available locations (data centers) doublezero location list -# Lister les points d'échange disponibles (points d'interconnexion) +# List available exchanges (interconnect points) doublezero exchange list ``` @@ -383,13 +349,13 @@ Enregistrez votre appareil sur la blockchain : ```bash doublezero device create \ - --code \ - --contributor \ + --code \ + --contributor \ --device-type hybrid \ - --location \ - --exchange \ - --public-ip \ - --dz-prefixes + --location \ + --exchange \ + --public-ip \ + --dz-prefixes ``` **Exemple :** @@ -419,26 +385,26 @@ doublezero device list | grep nyc-dz001 **Explication des paramètres :** -| Paramètre | Signification | +| Paramètre | Ce qu'il signifie | |-----------|---------------| -| `--code` | Un nom unique pour votre appareil (ex. `nyc-dz001`) | -| `--contributor` | Votre code contributeur (fourni par la DZF) | +| `--code` | Un nom unique pour votre appareil (par ex. `nyc-dz001`) | +| `--contributor` | Votre code contributeur (fourni par DZF) | | `--device-type` | `hybrid`, `transit` ou `edge` | -| `--location` | Code du data center depuis `location list` | -| `--exchange` | Code du point d'échange le plus proche depuis `exchange list` | +| `--location` | Code du centre de données depuis `location list` | +| `--exchange` | Code de l'échange le plus proche depuis `exchange list` | | `--public-ip` | L'IP publique par laquelle les utilisateurs se connectent à votre appareil via internet | | `--dz-prefixes` | Votre bloc d'IP alloué pour les utilisateurs | ### Étape 3.3 : Créer les interfaces loopback requises -Chaque appareil a besoin de deux interfaces loopback pour le routage interne : +Chaque appareil nécessite deux interfaces loopback pour le routage interne : ```bash -# Loopback VPNv4 -doublezero device interface create Loopback255 --loopback-type vpnv4 +# VPNv4 loopback +doublezero device interface create Loopback255 --loopback-type vpnv4 -# Loopback IPv4 -doublezero device interface create Loopback256 --loopback-type ipv4 +# IPv4 loopback +doublezero device interface create Loopback256 --loopback-type ipv4 ``` **Sortie attendue (pour chaque commande) :** @@ -452,8 +418,8 @@ Signature: 3mNx9K...truncated...8wRt5 Enregistrez les interfaces physiques qui seront utilisées pour les liens WAN ou DZX. Ces interfaces doivent exister on-chain avant que vous puissiez créer un lien qui les référence. À cette étape, vous enregistrez uniquement l'interface et sa bande passante ; le lien est créé dans une étape ultérieure. ```bash -doublezero device interface create \ - --bandwidth +doublezero device interface create \ + --bandwidth ``` **Exemple :** @@ -471,11 +437,11 @@ Signature: 7pQw2R...truncated...4xKm9 Répétez cette opération pour chaque interface qui sera utilisée comme point de terminaison d'un lien WAN ou DZX. Les interfaces CYOA et DIA sont enregistrées séparément à l'étape suivante. -### Étape 3.5 : Créer l'interface CYOA (pour les appareils Edge/Hybride) +### Étape 3.5 : Créer l'interface CYOA (pour les appareils Edge/Hybrides) -Les DZD hybrides et edge ont besoin de **deux adresses IP publiques** sur lesquelles les utilisateurs terminent leurs tunnels GRE. Les utilisateurs peuvent se connecter en unicast, multicast, ou les deux, et quelle IP sert quel objectif alterne par utilisateur. +Les DZD hybrides et edge nécessitent **deux adresses IP publiques** sur lesquelles les utilisateurs terminent leurs tunnels GRE. Les utilisateurs peuvent se connecter en unicast, multicast, ou les deux, et quelle IP sert quel objectif alterne selon l'utilisateur. -Les deux IP doivent être enregistrées avec `--user-tunnel-endpoint true`, soit sur une interface physique, soit sur un loopback. Cela inclut l'IP que vous avez fournie lors de la création de l'appareil ; cette IP doit tout de même être explicitement enregistrée ici. +Les deux IP doivent être enregistrées avec `--user-tunnel-endpoint true`, soit sur une interface physique, soit sur un loopback. Cela inclut l'IP que vous avez fournie lors de la création de l'appareil — cette IP doit quand même être explicitement enregistrée ici. Si vous êtes limité en IP, vous pouvez utiliser le premier `/32` de votre préfixe DZ comme l'une des deux IP. @@ -491,42 +457,42 @@ L'indicateur CYOA est toujours défini sur une **interface physique** (port Ethe | Sous-type CYOA | Quand l'utiliser | |-------------|-------------| | `gre-over-dia` | Les utilisateurs se connectent via l'internet public. Le plus courant. | -| `gre-over-private-peering` | Les utilisateurs se connectent via une interconnexion directe ou un circuit privé | -| `gre-over-public-peering` | Les utilisateurs peerent avec vous dans un point d'échange internet (IX) | +| `gre-over-private-peering` | Les utilisateurs se connectent via un cross-connect direct ou un circuit privé | +| `gre-over-public-peering` | Les utilisateurs peerent avec vous à un point d'échange Internet (IX) | | `gre-over-fabric` | Les utilisateurs sont colocalisés et se connectent via un fabric local | -| `gre-over-cable` | Connexion par câble direct vers un seul utilisateur dédié | +| `gre-over-cable` | Connexion par câble direct vers un utilisateur unique dédié | #### Scénario A : Interface physique unique -Une seule liaison montante physique vers le FAI. Ethernet1/1 est l'interface CYOA et DIA et porte l'une des deux IP publiques. Loopback100 porte la seconde IP publique. +Un seul lien montant physique vers le FAI. Ethernet1/1 est l'interface CYOA et DIA et porte l'une des deux IP publiques. Loopback100 porte la seconde IP publique. ```mermaid flowchart LR - USERS(["Utilisateurs finaux"]) + USERS(["End Users"]) subgraph DZD["DZD"] E1["Eth1/1 203.0.113.1/30 - CYOA · DIA · point de terminaison tunnel utilisateur"] + CYOA · DIA · user tunnel endpoint"] LO["Loopback100 - 198.51.100.1/32\n point de terminaison tunnel utilisateur"] + 198.51.100.1/32\n user tunnel endpoint"] E1 --- LO end - ISP["Routeur FAI + ISP["ISP Router 203.0.113.2/30"] ISP -- "10GbE" --- E1 - USERS -. "Tunnels GRE" .-> E1 - USERS -. "Tunnels GRE" .-> LO + USERS -. "GRE tunnels" .-> E1 + USERS -. "GRE tunnels" .-> LO ``` | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sous-réseau assigné par le contributeur | vitesse du port | débit garanti | `bgp` ou `static` | `true` | -| Loopback100 | — | — | votre /32 public | `0bps` | — | — | `true` | +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sous-réseau attribué par le contributeur | vitesse du port | débit garanti | `bgp` ou `static` | `true` | +| Loopback100 | — | — | votre /32 publique | `0bps` | — | — | `true` | -Exemple de commandes à exécuter pour le Scénario A : +Exemple de commandes à exécuter selon le scénario A : ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -545,31 +511,91 @@ doublezero device interface create mydzd-nyc01 Loopback100 \ #### Scénario B : Port channel (LAG) -Le DZD se connecte à l'équipement amont via un port channel avec une IP. Le port channel porte une IP publique et constitue le point de terminaison CYOA. Loopback100 porte la seconde IP publique. +Le DZD se connecte à l'équipement amont via un port channel avec une IP. Le port channel porte une IP publique et est le point de terminaison CYOA. Loopback100 porte la seconde IP publique. ```mermaid flowchart LR - USERS(["Utilisateurs finaux"]) + USERS(["End Users"]) - subgraph SW["Routeur / Switch amont"] + subgraph SW["Upstream Router / Switch"] SWPC(["bond0 203.0.113.2/30"]) end subgraph DZD["DZD"] - subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · point de terminaison tunnel utilisateur"] + subgraph PC["Port-Channel1 · 203.0.113.1/30 · CYOA · DIA · user tunnel endpoint"] E1["Eth1/1"] E2["Eth2/1"] end LO["Loopback100 - 198.51.100.1/32\n point de terminaison tunnel utilisateur"] + 198.51.100.1/32\n user tunnel endpoint"] PC --- LO end SWPC -- "2x 10GbE" --- PC - USERS -. "Tunnels GRE" .-> PC - USERS -. "Tunnels GRE" .-> LO + USERS -. "GRE tunnels" .-> PC + USERS -. "GRE tunnels" .-> LO ``` | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | -|-----------| \ No newline at end of file +|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +| Port-Channel1 | `gre-over-dia` | `dia` | IP/sous-réseau attribué par le contributeur | vitesse LAG combinée | débit garanti | `bgp` ou `static` | `true` | +| Loopback100 | — | — | votre /32 publique | `0bps` | — | — | `true` | + +Exemple de commandes à exécuter selon le scénario B : +```bash +doublezero device interface create mydzd-fra01 Port-Channel1 \ + --interface-cyoa gre-over-dia \ + --interface-dia dia \ + --ip-net 203.0.113.1/30 \ + --bandwidth 20Gbps \ + --cir 2Gbps \ + --routing-mode bgp \ + --user-tunnel-endpoint true + +doublezero device interface create mydzd-fra01 Loopback100 \ + --ip-net 198.51.100.1/32 \ + --bandwidth 0bps \ + --user-tunnel-endpoint true +``` + + +#### Scénario C : Double lien montant physique vers des routeurs séparés + +Chaque interface physique se connecte à un routeur amont différent. Les deux IP publiques sont sur Loopback100 et Loopback101, toutes deux enregistrées comme points de terminaison de tunnel utilisateur. + +```mermaid +flowchart LR + USERS(["End Users"]) + + RA["Router A + 203.0.113.2/30"] + RB["Router B + 203.0.113.6/30"] + + subgraph DZD["DZD"] + E1["Eth1/1 + 203.0.113.1/30 + CYOA · DIA"] + E2["Eth2/1 + 203.0.113.5/30 + CYOA · DIA"] + LO0["Loopback100 + 198.51.100.1/32\n user tunnel endpoint"] + LO1["Loopback101 + 198.51.100.2/32\n user tunnel endpoint"] + E1 --> LO0 + E2 --> LO1 + end + + RA -- "10GbE" --- E1 + RB -- "10GbE" --- E2 + USERS -. "GRE tunnels" .-> LO0 + USERS -. "GRE tunnels" .-> LO1 +``` + +| Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | +|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sous-réseau attribué par le contributeur | vitesse du port | débit garanti | `bgp` ou `static` | — | +| Ethernet2/1 | `gre-over-dia` | `dia` | IP/sous-réseau attribué par le contributeur | vitesse du port | débit garanti | `bgp` ou `static` | — | +| Loopback100 | — | — | votre /32 publique | `0bps` \ No newline at end of file diff --git a/docs/contribute-provisioning.it.md b/docs/contribute-provisioning.it.md index eb9ce41..c6ddb20 100644 --- a/docs/contribute-provisioning.it.md +++ b/docs/contribute-provisioning.it.md @@ -1,47 +1,47 @@ --- -description: Guida passo-passo per il provisioning di un DoubleZero Device (DZD) e la registrazione delle sue interfacce e ruoli on-chain. +description: Guida passo passo per il provisioning di un DoubleZero Device (DZD) e la registrazione delle sue interfacce e ruoli on-chain. --- -# Guida al Provisioning dei Dispositivi +# Guida al Provisioning del Dispositivo Questa guida ti accompagna nel provisioning di un DoubleZero Device (DZD) dall'inizio alla fine. Ogni fase corrisponde alla [Checklist di Onboarding](contribute-overview.md#onboarding-checklist). --- -## Come si integra il tutto +## Come si Collega il Tutto -Questa guida ti accompagna nella registrazione della tua infrastruttura on-chain in modo che la rete DoubleZero possa instradare il traffico attraverso di essa. Più la registrazione del tuo dispositivo è completa, più questo risulta utile per la rete. Una rappresentazione on-chain completa del tuo dispositivo consente un miglior troubleshooting, una migliore pianificazione della capacità e permette al controller di prendere decisioni informate. Nel tempo, l'obiettivo è che il controller assuma una parte sempre maggiore della responsabilità di configurazione. +Questa guida ti accompagna nella registrazione della tua infrastruttura on-chain in modo che la rete DoubleZero possa instradare il traffico attraverso di essa. Più la registrazione del tuo dispositivo è completa, più sarà utile alla rete. Una rappresentazione on-chain completa del tuo dispositivo consente un migliore troubleshooting, pianificazione della capacità, e permette al controller di prendere decisioni informate. Nel tempo, l'obiettivo è che il controller assuma sempre più responsabilità nella configurazione. ### Concetti chiave **Interfacce** -Le interfacce su un DZD si presentano in diverse forme: porte Ethernet, port channel (LAG composti da più porte Ethernet) e loopback. Ogni interfaccia che svolge un ruolo nella rete deve essere registrata on-chain con i flag appropriati affinché il protocollo sappia quale funzione svolge. +Le interfacce su un DZD si presentano in diverse forme: porte Ethernet, port channel (LAG composti da più porte Ethernet) e loopback. Ogni interfaccia che svolge un ruolo nella rete deve essere registrata on-chain con i flag appropriati affinché il protocollo sappia cosa fa. Le porte Ethernet e i port channel possono svolgere i seguenti ruoli: -| Flag | Significato | -|------|-------------| +| Flag | Cosa significa | +|------|---------------| | `--interface-dia dia` | Contrassegna l'interfaccia come uplink di accesso diretto a internet | -| `--interface-cyoa ` | Dichiara come gli utenti stabiliscono i tunnel GRE attraverso questa interfaccia (es. tramite internet pubblico, tramite un link di peering privato) | -| `--user-tunnel-endpoint true` | Questa interfaccia possiede un IP pubblico su cui gli utenti terminano i tunnel GRE | +| `--interface-cyoa ` | Dichiara come gli utenti stabiliscono tunnel GRE attraverso questa interfaccia (es. tramite internet pubblico, tramite un link di peering privato) | +| `--user-tunnel-endpoint true` | Questa interfaccia ha un IP pubblico su cui gli utenti terminano i tunnel GRE | -Le interfacce utilizzate per link WAN o DZX non hanno un flag specifico: vengono registrate con la loro larghezza di banda e poi referenziate quando il link viene creato. +Le interfacce utilizzate per link WAN o DZX non hanno un flag specifico, vengono registrate con la loro larghezza di banda e poi referenziate quando il link viene creato. -Le interfacce loopback svolgono diversi scopi: +Le interfacce loopback servono a diversi scopi: -| Loopback | Significato | -|----------|-------------| -| **Loopback100 / 101** | Portano IP pubblici su cui gli utenti terminano i tunnel GRE. Registrate con `--user-tunnel-endpoint true`. | -| **Loopback255** (`vpnv4`) | Registrata affinché il controller possa assegnare un IP utilizzato per il router ID BGP, il peering VPN-IPv4 (unicast), l'identità IS-IS e il segment routing | -| **Loopback256** (`ipv4`) | Registrata affinché il controller possa assegnare un IP utilizzato per il peering BGP IPv4 (multicast) e le sessioni MSDP | +| Loopback | Cosa significa | +|----------|---------------| +| **Loopback100 / 101** | Hanno IP pubblici su cui gli utenti terminano i tunnel GRE. Registrate con `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Registrata affinché il controller possa assegnare un IP utilizzato per BGP router ID, peering VPN-IPv4 (unicast), identità IS-IS e segment routing | +| **Loopback256** (`ipv4`) | Registrata affinché il controller possa assegnare un IP utilizzato per peering BGP IPv4 (multicast) e sessioni MSDP | **Link** -I link vengono registrati separatamente dalle interfacce, e le interfacce devono esistere on-chain prima che un link possa referenziarle. Quando crei un link WAN o DZX, specifichi un'interfaccia già registrata come endpoint fisico del link. Non tutte le interfacce sono associate a un link: le interfacce DIA, CYOA e loopback non sono collegate a un link. +I link sono registrati separatamente dalle interfacce, e le interfacce devono esistere on-chain prima che un link possa referenziarle. Quando crei un link WAN o DZX, specifichi un'interfaccia già registrata come endpoint fisico del link. Non tutte le interfacce sono collegate a un link: le interfacce DIA, CYOA e loopback non sono connesse a un link. -| Termine | Significato | -|---------|-------------| +| Termine | Cosa significa | +|---------|---------------| | **WAN Link** | Un link tra due dei tuoi DZD | | **DZX Link** | Un link tra il tuo DZD e il DZD di un altro contributore | @@ -81,22 +81,22 @@ flowchart TB ## Fase 1: Prerequisiti -Prima di poter effettuare il provisioning di un dispositivo, è necessario predisporre l'hardware fisico e allocare alcuni indirizzi IP. +Prima di poter effettuare il provisioning di un dispositivo, è necessario che l'hardware fisico sia configurato e che alcuni indirizzi IP siano allocati. -### Cosa ti serve +### Cosa Ti Serve -| Requisito | Perché è necessario | +| Requisito | Perché È Necessario | |-----------|---------------------| | **Hardware DZD** | Switch Arista 7280CR3A (vedi [specifiche hardware](contribute.md#hardware-requirements)) | -| **Spazio Rack** | 1U per DZD, con flusso d'aria adeguato. Vedi [Rack e Alimentazione](contribute.md#rack-power-requirements) | -| **Alimentazione** | Due linee di alimentazione indipendenti, ciascuna in grado di sostenere l'intero carico da sola. Vedi [Rack e Alimentazione](contribute.md#rack-power-requirements) | -| **Accesso di gestione** | Accesso SSH/console per configurare lo switch | -| **Connettività Internet** | Per la pubblicazione delle metriche e per ottenere la configurazione dal controller | +| **Spazio Rack** | 2U riservati per DZD (1U in uso oggi), con flusso d'aria adeguato. Vedi [Rack e Alimentazione](contribute.md#rack-power-requirements) | +| **Alimentazione** | Due linee indipendenti, ciascuna in grado di sostenere l'intero carico da sola. Vedi [Rack e Alimentazione](contribute.md#rack-power-requirements) | +| **Accesso di Gestione** | Accesso SSH/console per configurare lo switch | +| **Connettività Internet** | Per la pubblicazione delle metriche e per recuperare la configurazione dal controller | | **Blocco IPv4 Pubblico** | Minimo /29 per il pool di prefissi DZ (vedi sotto) | ### Installare la CLI DoubleZero -La CLI DoubleZero (`doublezero`) viene utilizzata durante tutto il provisioning per registrare dispositivi, creare link e gestire il tuo contributo. Deve essere installata su un **server di gestione o una VM** — non sullo switch DZD stesso. Lo switch esegue solo il Config Agent e il Telemetry Agent (installati nella [Fase 4](#fase-4-creazione-dei-link-e-installazione-degli-agent)). +La CLI DoubleZero (`doublezero`) viene utilizzata durante tutto il provisioning per registrare dispositivi, creare link e gestire il tuo contributo. Deve essere installata su un **server di gestione o VM** — non sullo switch DZD stesso. Lo switch esegue solo il Config Agent e il Telemetry Agent (installati nella [Fase 4](#fase-4-creazione-dei-link-e-installazione-degli-agenti)). **Ubuntu / Debian:** ```bash @@ -115,7 +115,7 @@ Verifica che il daemon sia in esecuzione: sudo systemctl status doublezerod ``` -### Comprendere il tuo prefisso DZ +### Comprendere il Tuo Prefisso DZ Il tuo prefisso DZ è un blocco di indirizzi IP pubblici che il protocollo DoubleZero gestisce per l'allocazione IP. @@ -137,13 +137,13 @@ flowchart LR **Come vengono utilizzati i prefissi DZ:** - **Primo IP**: Riservato per il tuo dispositivo (assegnato all'interfaccia Loopback100) -- **IP rimanenti**: Allocati a specifici tipi di utenti che si connettono al tuo DZD: +- **IP rimanenti**: Allocati a tipi specifici di utenti che si connettono al tuo DZD: - Utenti `IBRLWithAllocatedIP` - Utenti `EdgeFiltering` (caso d'uso futuro) -- **Utenti IBRL**: NON consumano da questo pool (usano il proprio IP pubblico) +- **Utenti IBRL**: NON consumano da questo pool (utilizzano il proprio IP pubblico) -!!! warning "Regole del Prefisso DZ" - **NON puoi usare questi indirizzi per:** +!!! warning "Regole sui Prefissi DZ" + **NON PUOI utilizzare questi indirizzi per:** - Le tue apparecchiature di rete - Link punto-punto sulle interfacce DIA @@ -154,23 +154,23 @@ flowchart LR - Devono essere indirizzi IPv4 **globalmente instradabili (pubblici)** - Gli intervalli IP privati (10.x, 172.16-31.x, 192.168.x) vengono rifiutati dallo smart contract - - **Dimensione minima: /29** (8 indirizzi), prefissi più grandi sono preferibili (es. /28, /27) + - **Dimensione minima: /29** (8 indirizzi), prefissi più grandi sono preferiti (es. /28, /27) - L'intero blocco deve essere disponibile — non pre-allocare alcun indirizzo - Se hai bisogno di indirizzi per le tue apparecchiature (IP delle interfacce DIA, gestione, ecc.), usa un **pool di indirizzi separato**. + Se hai bisogno di indirizzi per le tue apparecchiature (IP per interfacce DIA, gestione, ecc.), utilizza un **pool di indirizzi separato**. --- -## Fase 2: Configurazione dell'account +## Fase 2: Configurazione dell'Account -In questa fase, crei le chiavi crittografiche che ti identificano te e i tuoi dispositivi sulla rete, e indichi dove devono essere pagati i tuoi reward. +In questa fase, crei le chiavi crittografiche che ti identificano, insieme ai tuoi dispositivi, sulla rete, e configuri la gestione dei premi. -Da questa fase si ottengono tre chiavi: una chiave di servizio, una chiave per la pubblicazione delle metriche e una chiave per la gestione dei reward. Invia le chiavi pubbliche di tutte e tre alla DZF insieme nel [Passo 2.4](#passo-24-inviare-le-chiavi-alla-dzf). [Gestione dei Reward](contribute-rewards.md) copre in dettaglio il lato dei reward. +I passaggi vengono eseguiti in questo ordine per un motivo: prima l'accesso al repository, perché il repository contiene le istruzioni per i passaggi successivi, poi le tue chiavi, poi i premi. Alcuni passaggi richiedono un intervento di DZF prima che tu possa continuare, e ciascuno di quelli sotto lo specifica. -### Dove eseguire la CLI +### Dove Eseguire la CLI !!! warning "NON installare la CLI sul tuo switch" - La CLI DoubleZero (`doublezero`) deve essere installata su un **server di gestione o una VM**, non sul tuo switch Arista. + La CLI DoubleZero (`doublezero`) deve essere installata su un **server di gestione o VM**, non sul tuo switch Arista. ```mermaid flowchart LR @@ -189,19 +189,19 @@ Da questa fase si ottengono tre chiavi: una chiave di servizio, una chiave per l TA -->|Submits metrics| BC ``` - | Installare sul server di gestione | Installare sullo switch | - |----------------------------------|------------------------| + | Installare sul Server di Gestione | Installare sullo Switch | + |-----------------------------------|------------------------| | CLI `doublezero` | Config Agent | - | Il tuo keypair di servizio | Telemetry Agent | - | Il tuo keypair per la pubblicazione delle metriche | Keypair per la pubblicazione delle metriche (copia) | + | La tua keypair di servizio | Telemetry Agent | + | La tua keypair del metrics publisher | Keypair del metrics publisher (copia) | -### Cosa sono le chiavi? +### Cosa Sono le Chiavi? Pensa alle chiavi come credenziali di accesso sicure: -- **Chiave di servizio**: La tua identità come contributore — usata per eseguire i comandi CLI -- **Chiave per la pubblicazione delle metriche**: L'identità del tuo dispositivo per l'invio dei dati di telemetria -- **Chiave per la gestione dei reward**: Controlla quali wallet ricevono i tuoi reward — vedi [Gestione dei Reward](contribute-rewards.md) +- **Service Key**: La tua identità come contributore — utilizzata per eseguire comandi CLI +- **Metrics Publisher Key**: L'identità del tuo dispositivo per l'invio di dati telemetrici +- **Rewards Manager Key**: Controlla quali wallet ricevono i tuoi premi — vedi [Gestione Premi](https://github.com/malbeclabs/contributors#rewards-management) nel repository dei contributori Tutte e tre sono coppie di chiavi crittografiche (una chiave pubblica che condividi, una chiave privata che mantieni segreta). @@ -218,10 +218,16 @@ flowchart LR RK -->|Used for| REW[Rewards Portal
Sets recipient wallets] ``` -!!! note "Tieni la chiave per la gestione dei reward separata" - La chiave di servizio e la chiave per la pubblicazione delle metriche risiedono sul tuo server di gestione e sullo switch. La chiave per la gestione dei reward controlla dove vanno i tuoi fondi, quindi tienila lontana da queste macchine. È necessaria solo quando cambi i tuoi wallet destinatari. +!!! note "Mantieni la chiave del rewards manager separata" + La service key e la metrics publisher key risiedono sul tuo server di gestione e sullo switch. La rewards manager key controlla dove vanno i tuoi soldi, quindi tienila lontano da quelle macchine. È necessaria solo quando modifichi i tuoi wallet destinatari. -### Passo 2.1: Generare la chiave di servizio +### Passo 2.1: Richiedere l'Accesso al Repository dei Contributori + +Contatta la DoubleZero Foundation o Malbec Labs e fornisci il tuo **nome utente GitHub**. + +Ti concederanno l'accesso al repository privato [malbeclabs/contributors](https://github.com/malbeclabs/contributors). Fai questo per primo: il repository contiene la configurazione base del dispositivo, i profili TCAM e ACL, e le istruzioni per la gestione dei premi di cui hai bisogno nei passaggi successivi. + +### Passo 2.2: Generare la Tua Service Key Questa è la tua identità principale per interagire con DoubleZero. @@ -229,9 +235,9 @@ Questa è la tua identità principale per interagire con DoubleZero. doublezero keygen ``` -Questo crea un keypair nella posizione predefinita. L'output mostra la tua **chiave pubblica** — è quella che condividerai con la DZF. +Questo crea una coppia di chiavi nella posizione predefinita. L'output mostra la tua **chiave pubblica** — questa è ciò che condividerai con DZF. -### Passo 2.2: Generare la chiave per la pubblicazione delle metriche +### Passo 2.3: Generare la Tua Metrics Publisher Key Questa chiave viene utilizzata dal Telemetry Agent per firmare l'invio delle metriche. @@ -239,34 +245,16 @@ Questa chiave viene utilizzata dal Telemetry Agent per firmare l'invio delle met doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Passo 2.3: Creare il wallet per la gestione dei reward - -Questa è la terza chiave. Controlla quali wallet ricevono i tuoi reward, e non li custodisce mai direttamente. - -Crea un wallet Solana che controlli e con cui puoi firmare, poi finanzialo con circa 0.01 SOL per coprire le commissioni di transazione. Un hardware wallet è una buona scelta. Non riutilizzare la tua chiave di servizio. +### Passo 2.4: Inviare la Tua Service Key a DZF -A questo punto hai bisogno solo del wallet. Imposterai i wallet che riceveranno effettivamente i tuoi reward nel [Passo 2.7](#passo-27-impostare-i-destinatari-dei-reward), dopo che la DZF avrà registrato questa chiave. +Invia a DZF la **chiave pubblica della tua service key**. -### Passo 2.4: Inviare le chiavi alla DZF - -Contatta la DoubleZero Foundation o Malbec Labs e fornisci: - -1. La tua **chiave pubblica di servizio** -2. La tua **chiave pubblica per la gestione dei reward** (dal Passo 2.3) -3. Il tuo **username GitHub** (per l'accesso al repository) - -Inviale tutte e tre insieme. La DZF registra la chiave di servizio e la chiave per la gestione dei reward in transazioni onchain separate, quindi inviarle contemporaneamente risparmia un passaggio. +Creeranno il tuo **account contributore** on-chain e confermeranno quando sarà completato. !!! danger "Solo chiavi pubbliche" - Non inviare mai una chiave privata o un file keypair a nessuno, inclusa la DZF. La DZF ha bisogno solo delle tue chiavi pubbliche. - -Loro faranno: - -- Creare il tuo **account contributore** onchain -- Registrare la tua **chiave per la gestione dei reward** associata alla tua chiave di servizio -- Concedere l'accesso al **repository privato dei contributori** + Non inviare mai una chiave privata o un file di coppia di chiavi a nessuno, incluso DZF. Solo la chiave pubblica è necessaria. -### Passo 2.5: Verificare il tuo account +### Passo 2.5: Verificare il Tuo Account Una volta confermato, verifica che il tuo account contributore esista: @@ -274,46 +262,24 @@ Una volta confermato, verifica che il tuo account contributore esista: doublezero contributor list ``` -Dovresti vedere il tuo codice contributore nella lista. - -Verifica anche che la tua chiave per la gestione dei reward sia stata registrata: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` - -La colonna `manager` dovrebbe mostrare la tua chiave pubblica per la gestione dei reward. Se è vuota, chiedi alla DZF di completare quel passaggio. - -### Passo 2.6: Accedere al repository dei contributori - -Il repository [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contiene: - -- Configurazioni base dei dispositivi -- Profili TCAM -- Configurazioni ACL -- Istruzioni di configurazione aggiuntive - -Segui le istruzioni presenti per la configurazione specifica del dispositivo. - -### Passo 2.7: Impostare i destinatari dei reward +Dovresti vedere il tuo codice contributore nell'elenco. -Ora indica quali wallet ricevono i tuoi reward e in quali proporzioni. Fallo prima che il tuo dispositivo inizi a trasportare traffico. I reward si accumulano dal momento in cui i tuoi link sono attivi, ma il protocollo non può erogarli finché non hai nominato i wallet destinatari. +### Passo 2.6: Configurare la Gestione dei Premi -Accedi a [doublezero.xyz/rewards](https://doublezero.xyz/rewards) con il tuo wallet per la gestione dei reward, seleziona la tua chiave di servizio, poi inserisci ciascun wallet destinatario e la sua percentuale. Le percentuali devono sommare a 100. +La gestione dei premi decide quali wallet ricevono i [2Z](glossary.md#2z-token) guadagnati dal tuo contributo, e in quali proporzioni. -!!! warning "Ogni destinatario necessita di un token account 2Z" - Il protocollo invia 2Z con un semplice trasferimento di token e non crea il token account al posto tuo. Un wallet destinatario senza token account 2Z causa il fallimento del pagamento di quell'epoca. +Segui la [Gestione Premi](https://github.com/malbeclabs/contributors#rewards-management) nel repository dei contributori, a cui ora hai accesso dal Passo 2.1. -Vedi [Gestione dei Reward](contribute-rewards.md) per la guida completa, inclusa l'alternativa tramite CLI, come verificare il token account e come verificare il risultato. +!!! note "Questo non blocca il resto della tua configurazione" + Puoi effettuare il provisioning del tuo dispositivo, creare link e iniziare a trasportare traffico senza che questo sia in atto, quindi considera le fasi successive come indipendenti da esso. --- -## Fase 3: Provisioning del dispositivo +## Fase 3: Provisioning del Dispositivo Ora registrerai il tuo dispositivo fisico sulla blockchain e configurerai le sue interfacce. -### Comprendere i tipi di dispositivo +### Comprendere i Tipi di Dispositivo **Edge** — accetta solo connessioni utente @@ -330,7 +296,7 @@ flowchart LR E_DZX <-->|DZX Link| ED["DZD (different contributor)"] ``` -**Transit** — muove il traffico tra dispositivi, nessuna connessione utente +**Transit** — trasporta traffico tra dispositivi, nessuna connessione utente ```mermaid flowchart LR @@ -359,25 +325,25 @@ flowchart LR H_DZX <-->|DZX Link| HD["DZD (different contributor)"] ``` -| Tipo | Cosa fa | Quando usarlo | +| Tipo | Cosa Fa | Quando Usarlo | |------|---------|---------------| | **Edge** | Accetta solo connessioni utente | Singola posizione, solo rivolto agli utenti | -| **Transit** | Muove il traffico tra dispositivi | Connettività backbone, nessun utente | +| **Transit** | Trasporta traffico tra dispositivi | Connettività backbone, nessun utente | | **Hybrid** | Sia connessioni utente CHE backbone | Il più comune — fa tutto | -### Passo 3.1: Trovare la tua posizione e exchange +### Passo 3.1: Trovare la Tua Posizione e il Tuo Exchange Prima di creare il tuo dispositivo, cerca i codici per la posizione del tuo data center e l'exchange più vicino: ```bash -# Elencare le posizioni disponibili (data center) +# Elenco delle posizioni disponibili (data center) doublezero location list -# Elencare gli exchange disponibili (punti di interconnessione) +# Elenco degli exchange disponibili (punti di interconnessione) doublezero exchange list ``` -### Passo 3.2: Creare il tuo dispositivo onchain +### Passo 3.2: Creare il Tuo Dispositivo On-chain Registra il tuo dispositivo sulla blockchain: @@ -419,17 +385,17 @@ doublezero device list | grep nyc-dz001 **Spiegazione dei parametri:** -| Parametro | Significato | -|-----------|-------------| +| Parametro | Cosa Significa | +|-----------|----------------| | `--code` | Un nome univoco per il tuo dispositivo (es. `nyc-dz001`) | -| `--contributor` | Il tuo codice contributore (fornito dalla DZF) | +| `--contributor` | Il tuo codice contributore (fornito da DZF) | | `--device-type` | `hybrid`, `transit` o `edge` | | `--location` | Codice del data center da `location list` | | `--exchange` | Codice dell'exchange più vicino da `exchange list` | -| `--public-ip` | L'IP pubblico tramite cui gli utenti si connettono al tuo dispositivo via internet | +| `--public-ip` | L'IP pubblico dove gli utenti si connettono al tuo dispositivo via internet | | `--dz-prefixes` | Il tuo blocco IP allocato per gli utenti | -### Passo 3.3: Creare le interfacce loopback richieste +### Passo 3.3: Creare le Interfacce Loopback Richieste Ogni dispositivo necessita di due interfacce loopback per il routing interno: @@ -447,9 +413,9 @@ doublezero device interface create Loopback256 --loopback-type ipv Signature: 3mNx9K...truncated...8wRt5 ``` -### Passo 3.4: Creare le interfacce fisiche +### Passo 3.4: Creare le Interfacce Fisiche -Registra le interfacce fisiche che verranno utilizzate per i link WAN o DZX. Queste interfacce devono esistere on-chain prima che tu possa creare un link che le referenzia. In questo passo registri solo l'interfaccia e la sua larghezza di banda; il link viene creato in un passo successivo. +Registra le interfacce fisiche che saranno utilizzate per link WAN o DZX. Queste interfacce devono esistere on-chain prima di poter creare un link che le referenzi. In questo passaggio registri solo l'interfaccia e la sua larghezza di banda, il link viene creato in un passaggio successivo. ```bash doublezero device interface create \ @@ -469,15 +435,15 @@ doublezero device interface create nyc-dz001 Ethernet1/1 \ Signature: 7pQw2R...truncated...4xKm9 ``` -Ripeti per ogni interfaccia che verrà utilizzata come endpoint di un link WAN o DZX. Le interfacce CYOA e DIA vengono registrate separatamente nel passo successivo. +Ripeti questo per ogni interfaccia che sarà utilizzata come endpoint di un link WAN o DZX. Le interfacce CYOA e DIA vengono registrate separatamente nel passaggio successivo. -### Passo 3.5: Creare l'interfaccia CYOA (per dispositivi Edge/Hybrid) +### Passo 3.5: Creare l'Interfaccia CYOA (per dispositivi Edge/Hybrid) -I DZD hybrid e edge necessitano di **due indirizzi IP pubblici** su cui gli utenti terminano i loro tunnel GRE. Gli utenti possono connettersi tramite unicast, multicast o entrambi, e quale IP serve quale scopo ruota per ogni utente. +I DZD hybrid ed edge necessitano di **due indirizzi IP pubblici** su cui gli utenti terminano i loro tunnel GRE. Gli utenti possono connettersi tramite unicast, multicast o entrambi, e quale IP serve quale scopo ruota per utente. -Entrambi gli IP devono essere registrati con `--user-tunnel-endpoint true`, su un'interfaccia fisica o un loopback. Questo include l'IP che hai fornito al momento della creazione del dispositivo: quell'IP deve comunque essere registrato esplicitamente qui. +Entrambi gli IP devono essere registrati con `--user-tunnel-endpoint true`, su un'interfaccia fisica o un loopback. Questo include l'IP che hai fornito al momento della creazione del dispositivo, quell'IP deve comunque essere esplicitamente registrato qui. -Se hai vincoli di IP, puoi utilizzare il primo `/32` del tuo prefisso DZ come uno dei due IP. +Se hai vincoli sugli IP, puoi utilizzare il primo `/32` del tuo prefisso DZ come uno dei due IP. #### CYOA e DIA @@ -491,10 +457,10 @@ Il flag CYOA viene sempre impostato su un'**interfaccia fisica** (porta Ethernet | Sottotipo CYOA | Quando usarlo | |----------------|---------------| | `gre-over-dia` | Gli utenti si connettono tramite internet pubblico. Il più comune. | -| `gre-over-private-peering` | Gli utenti si connettono tramite una cross-connect diretta o un circuito privato | -| `gre-over-public-peering` | Gli utenti fanno peering con te presso un Internet Exchange (IX) | +| `gre-over-private-peering` | Gli utenti si connettono tramite cross-connect diretto o circuito privato | +| `gre-over-public-peering` | Gli utenti fanno peering con te in un Internet Exchange (IX) | | `gre-over-fabric` | Gli utenti sono co-locati e si connettono tramite un fabric locale | -| `gre-over-cable` | Connessione diretta via cavo a un singolo utente dedicato | +| `gre-over-cable` | Connessione via cavo diretto a un singolo utente dedicato | #### Scenario A: Singola interfaccia fisica @@ -523,10 +489,10 @@ flowchart LR | Interfaccia | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità della porta | tasso garantito | `bgp` o `static` | `true` | +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità della porta | rate garantito | `bgp` o `static` | `true` | | Loopback100 | — | — | il tuo /32 pubblico | `0bps` | — | — | `true` | -Esempio di comandi da eseguire per lo Scenario A: +Esempio di comandi da eseguire basati sullo Scenario A: ```bash doublezero device interface create mydzd-nyc01 Ethernet1/1 \ --interface-cyoa gre-over-dia \ @@ -573,10 +539,10 @@ flowchart LR | Interfaccia | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità LAG combinata | tasso garantito | `bgp` o `static` | `true` | +| Port-Channel1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità LAG combinata | rate garantito | `bgp` o `static` | `true` | | Loopback100 | — | — | il tuo /32 pubblico | `0bps` | — | — | `true` | -Esempio di comandi da eseguire per lo Scenario B: +Esempio di comandi da eseguire basati sullo Scenario B: ```bash doublezero device interface create mydzd-fra01 Port-Channel1 \ --interface-cyoa gre-over-dia \ @@ -594,9 +560,9 @@ doublezero device interface create mydzd-fra01 Loopback100 \ ``` -#### Scenario C: Doppio uplink fisico verso router separati +#### Scenario C: Doppi uplink fisici verso router separati -Ogni interfaccia fisica si connette a un router upstream diverso. I due IP pubblici risiedono su Loopback100 e Loopback101, entrambi registrati come endpoint per i tunnel utente. +Ogni interfaccia fisica si connette a un router upstream diverso. I due IP pubblici risiedono su Loopback100 e Loopback101, entrambi registrati come user tunnel endpoint. ```mermaid flowchart LR @@ -616,4 +582,41 @@ flowchart LR CYOA · DIA"] LO0["Loopback100 198.51.100.1/32\n user tunnel endpoint"] - L \ No newline at end of file + LO1["Loopback101 + 198.51.100.2/32\n user tunnel endpoint"] + E1 --> LO0 + E2 --> LO1 + end + + RA -- "10GbE" --- E1 + RB -- "10GbE" --- E2 + USERS -. "GRE tunnels" .-> LO0 + USERS -. "GRE tunnels" .-> LO1 +``` + +| Interfaccia | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | +|-------------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità della porta | rate garantito | `bgp` o `static` | — | +| Ethernet2/1 | `gre-over-dia` | `dia` | IP/subnet assegnato dal contributore | velocità della porta | rate garantito | `bgp` o `static` | — | +| Loopback100 | — | — | il tuo /32 pubblico | `0bps` | — | — | `true` | +| Loopback101 | — | — | il tuo /32 pubblico | `0bps` | — | — | `true` | + +Esempio di comandi da eseguire basati sullo Scenario C: +```bash +doublezero device interface create mydzd-ams01 Ethernet1/1 \ + --interface-cyoa gre-over-dia \ + --interface-dia dia \ + --ip-net 203.0.113.1/30 \ + --bandwidth 10Gbps \ + --cir 1Gbps \ + --routing-mode bgp + +doublezero device interface create mydzd-ams01 Ethernet2/1 \ + --interface-cyoa gre-over-dia \ + --interface-dia dia \ + --ip-net 203.0.113.5/30 \ + --bandwidth 10Gbps \ + --cir 1Gbps \ + --routing-mode bgp + +doublezero device interface create mydzd- \ No newline at end of file diff --git a/docs/contribute-provisioning.ja.md b/docs/contribute-provisioning.ja.md index ef50d6f..3176ee9 100644 --- a/docs/contribute-provisioning.ja.md +++ b/docs/contribute-provisioning.ja.md @@ -1,49 +1,49 @@ --- -description: DoubleZero デバイス（DZD）のプロビジョニングおよびインターフェースとロールのオンチェーン登録に関するステップバイステップガイド。 +description: DoubleZero Device (DZD) のプロビジョニングとインターフェースおよびロールのオンチェーン登録に関するステップバイステップガイド。 --- # デバイスプロビジョニングガイド -このガイドでは、DoubleZero デバイス（DZD）のプロビジョニングを最初から最後まで手順を追って説明します。各フェーズは[オンボーディングチェックリスト](contribute-overview.md#onboarding-checklist)に対応しています。 +このガイドでは、DoubleZero Device (DZD) のプロビジョニングを最初から最後まで順を追って説明します。各フェーズは[オンボーディングチェックリスト](contribute-overview.md#onboarding-checklist)に対応しています。 --- ## 全体の仕組み -このガイドでは、DoubleZero ネットワークがインフラストラクチャを通じてトラフィックをルーティングできるように、インフラストラクチャをオンチェーンに登録する手順を説明します。デバイスの登録が完全であるほど、ネットワークにとってより有用なものとなります。デバイスの完全なオンチェーン表現により、トラブルシューティング、キャパシティプランニングが改善され、コントローラーが適切な判断を行えるようになります。将来的には、コントローラーがより多くの構成責任を担うことが目標です。 +このガイドでは、DoubleZero ネットワークがトラフィックをルーティングできるように、インフラストラクチャをオンチェーンに登録する手順を説明します。デバイスの登録が完全であるほど、ネットワークにとっての有用性が高まります。デバイスの完全なオンチェーン表現により、トラブルシューティングやキャパシティプランニングが改善され、コントローラーが適切な判断を下せるようになります。将来的には、コントローラーが設定の責任をより多く担うことを目指しています。 ### 主要な概念 **インターフェース** -DZD のインターフェースにはさまざまな形態があります：イーサネットポート、ポートチャネル（複数のイーサネットポートで構成される LAG）、ループバックです。ネットワークで役割を持つ各インターフェースは、プロトコルがその役割を認識できるよう、適切なフラグを付けてオンチェーンに登録する必要があります。 +DZD のインターフェースにはさまざまな形態があります：イーサネットポート、ポートチャネル（複数のイーサネットポートで構成される LAG）、およびループバックです。ネットワーク上で役割を持つ各インターフェースは、プロトコルがその機能を認識できるよう、適切なフラグを付けてオンチェーンに登録する必要があります。 イーサネットポートとポートチャネルは以下の役割を果たすことができます： | フラグ | 意味 | |------|---------------| -| `--interface-dia dia` | インターフェースをダイレクトインターネットアクセスのアップリンクとしてマーク | -| `--interface-cyoa ` | ユーザーがこのインターフェースを通じて GRE トンネルを確立する方法を宣言（例：パブリックインターネット経由、プライベートピアリングリンク経由） | -| `--user-tunnel-endpoint true` | このインターフェースはユーザーが GRE トンネルを終端するパブリック IP を持つ | +| `--interface-dia dia` | インターフェースをダイレクトインターネットアクセスのアップリンクとしてマークします | +| `--interface-cyoa ` | ユーザーがこのインターフェースを通じて GRE トンネルを確立する方法を宣言します（例：パブリックインターネット経由、プライベートピアリングリンク経由） | +| `--user-tunnel-endpoint true` | このインターフェースはユーザーが GRE トンネルを終端するパブリック IP を持っています | -WAN または DZX リンクに使用されるインターフェースには特定のフラグは付きません。帯域幅とともに登録され、リンク作成時に参照されます。 +WAN または DZX リンクに使用されるインターフェースには特定のフラグは付けられず、帯域幅とともに登録され、リンク作成時に参照されます。 -ループバックインターフェースにはいくつかの目的があります： +ループバックインターフェースはいくつかの目的に使用されます： | ループバック | 意味 | |----------|---------------| -| **Loopback100 / 101** | ユーザーが GRE トンネルを終端するパブリック IP を持つ。`--user-tunnel-endpoint true` で登録。 | -| **Loopback255** (`vpnv4`) | コントローラーが BGP ルーター ID、VPN-IPv4 ピアリング（ユニキャスト）、IS-IS アイデンティティ、セグメントルーティングに使用する IP を割り当てられるよう登録 | -| **Loopback256** (`ipv4`) | コントローラーが IPv4 BGP ピアリング（マルチキャスト）および MSDP セッションに使用する IP を割り当てられるよう登録 | +| **Loopback100 / 101** | ユーザーが GRE トンネルを終端するパブリック IP を持ちます。`--user-tunnel-endpoint true` で登録します。 | +| **Loopback255** (`vpnv4`) | コントローラーが BGP ルーター ID、VPN-IPv4 ピアリング（ユニキャスト）、IS-IS アイデンティティ、およびセグメントルーティングに使用する IP を割り当てるために登録します | +| **Loopback256** (`ipv4`) | コントローラーが IPv4 BGP ピアリング（マルチキャスト）および MSDP セッションに使用する IP を割り当てるために登録します | **リンク** -リンクはインターフェースとは別に登録され、リンクがインターフェースを参照するには、インターフェースが先にオンチェーンに存在している必要があります。WAN または DZX リンクを作成する際、リンクの物理エンドポイントとして既に登録済みのインターフェースを指定します。すべてのインターフェースがリンクに紐づくわけではありません：DIA、CYOA、ループバックインターフェースはリンクに接続されません。 +リンクはインターフェースとは別に登録され、リンクがインターフェースを参照するには、インターフェースがオンチェーンに存在している必要があります。WAN または DZX リンクを作成する際には、既に登録済みのインターフェースをリンクの物理エンドポイントとして指定します。すべてのインターフェースがリンクに紐づくわけではありません：DIA、CYOA、およびループバックインターフェースはリンクに接続されません。 | 用語 | 意味 | |------|---------------| -| **WAN リンク** | 自分が所有する 2 つの DZD 間のリンク | -| **DZX リンク** | 自分の DZD と他のコントリビューターの DZD 間のリンク | +| **WAN リンク** | 自身の DZD 間のリンク | +| **DZX リンク** | 自身の DZD と別のコントリビューターの DZD 間のリンク | ### アーキテクチャ概要 @@ -79,7 +79,7 @@ flowchart TB --- -## フェーズ 1：前提条件 +## フェーズ 1: 前提条件 デバイスをプロビジョニングする前に、物理ハードウェアのセットアップといくつかの IP アドレスの割り当てが必要です。 @@ -88,15 +88,15 @@ flowchart TB | 要件 | 必要な理由 | |-------------|-----------------| | **DZD ハードウェア** | Arista 7280CR3A スイッチ（[ハードウェア仕様](contribute.md#hardware-requirements)を参照） | -| **ラックスペース** | DZD あたり 1U、適切なエアフローを確保。[ラック＆電源](contribute.md#rack-power-requirements)を参照 | -| **電源** | 2 系統の独立した電源フィード、各系統が単独で全負荷を賄えること。[ラック＆電源](contribute.md#rack-power-requirements)を参照 | -| **管理アクセス** | スイッチ設定のための SSH/コンソールアクセス | +| **ラックスペース** | DZD あたり 2U を確保（現在使用中は 1U）、適切なエアフローが必要。[ラックと電源](contribute.md#rack-power-requirements)を参照 | +| **電源** | 2 系統の独立した電源フィード、各系統が単独で全負荷を支えられること。[ラックと電源](contribute.md#rack-power-requirements)を参照 | +| **管理アクセス** | スイッチを設定するための SSH/コンソールアクセス | | **インターネット接続** | メトリクスの公開およびコントローラーからの設定取得用 | | **パブリック IPv4 ブロック** | DZ プレフィックスプール用に最低 /29（下記参照） | ### DoubleZero CLI のインストール -DoubleZero CLI（`doublezero`）は、プロビジョニング全体を通じてデバイスの登録、リンクの作成、コントリビューションの管理に使用されます。**管理サーバーまたは VM** にインストールしてください — DZD スイッチ本体にはインストールしないでください。スイッチには Config Agent と Telemetry Agent のみがインストールされます（[フェーズ 4](#phase-4-link-establishment-agent-installation) でインストール）。 +DoubleZero CLI（`doublezero`）は、プロビジョニング全体を通じてデバイスの登録、リンクの作成、コントリビューションの管理に使用されます。**管理サーバーまたは VM** にインストールしてください — DZD スイッチ自体にはインストールしないでください。スイッチには Config Agent と Telemetry Agent のみが実行されます（[フェーズ 4](#phase-4-link-establishment-agent-installation) でインストール）。 **Ubuntu / Debian:** ```bash @@ -110,14 +110,14 @@ curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.rpm.sh | sudo yum install doublezero ``` -デーモンが実行中であることを確認： +デーモンが実行中であることを確認します： ```bash sudo systemctl status doublezerod ``` -### DZ プレフィックスについて +### DZ プレフィックスの理解 -DZ プレフィックスは、DoubleZero プロトコルが IP 割り当てを管理するパブリック IP アドレスのブロックです。 +DZ プレフィックスは、DoubleZero プロトコルが IP 割り当てのために管理するパブリック IP アドレスのブロックです。 ```mermaid flowchart LR @@ -136,41 +136,41 @@ flowchart LR **DZ プレフィックスの使用方法：** -- **最初の IP**：デバイス用に予約（Loopback100 インターフェースに割り当て） -- **残りの IP**：DZD に接続する特定のユーザータイプに割り当て： +- **最初の IP**: デバイス用に予約（Loopback100 インターフェースに割り当て） +- **残りの IP**: DZD に接続する特定のユーザータイプに割り当て： - `IBRLWithAllocatedIP` ユーザー - `EdgeFiltering` ユーザー（将来のユースケース） -- **IBRL ユーザー**：このプールからは消費しません（独自のパブリック IP を使用） +- **IBRL ユーザー**: このプールからは消費しません（独自のパブリック IP を使用） !!! warning "DZ プレフィックスのルール" - **これらのアドレスを以下の用途に使用することはできません：** + **これらのアドレスを以下の目的で使用することはできません：** - - 自社のネットワーク機器 + - 自身のネットワーク機器 - DIA インターフェースのポイントツーポイントリンク - 管理インターフェース - DZ プロトコル外のインフラストラクチャ **要件：** - - **グローバルにルーティング可能な（パブリック）** IPv4 アドレスである必要があります - - プライベート IP レンジ（10.x、172.16-31.x、192.168.x）はスマートコントラクトにより拒否されます - - **最小サイズ：/29**（8 アドレス）、より大きなプレフィックスが推奨（例：/28、/27） - - ブロック全体が利用可能である必要があります — アドレスを事前に割り当てないでください + - **グローバルにルーティング可能（パブリック）** な IPv4 アドレスである必要があります + - プライベート IP レンジ（10.x、172.16-31.x、192.168.x）はスマートコントラクトによって拒否されます + - **最小サイズ: /29**（8 アドレス）、より大きなプレフィックスが推奨（例：/28、/27） + - ブロック全体が利用可能である必要があります — アドレスの事前割り当てはしないでください - 自社機器用のアドレス（DIA インターフェース IP、管理用など）が必要な場合は、**別のアドレスプール**を使用してください。 + 自身の機器用のアドレス（DIA インターフェース IP、管理用など）が必要な場合は、**別のアドレスプール**を使用してください。 --- -## フェーズ 2：アカウントセットアップ +## フェーズ 2: アカウントセットアップ -このフェーズでは、ネットワーク上であなたとデバイスを識別する暗号鍵を作成し、報酬の送付先を指定します。 +このフェーズでは、ネットワーク上であなたとデバイスを識別する暗号鍵を作成し、報酬管理を設定します。 -このフェーズでは 3 つの鍵が生成されます：サービスキー、メトリクスパブリッシャーキー、報酬マネージャーキーです。3 つすべての公開鍵を[ステップ 2.4](#step-24-submit-keys-to-dzf) でまとめて DZF に提出してください。[報酬管理](contribute-rewards.md)で報酬に関する詳細を説明しています。 +手順がこの順序で実行されるのには理由があります：まずリポジトリアクセス（リポジトリには後続のステップの手順が含まれているため）、次に鍵、そして報酬。一部のステップでは DZF の対応を待つ必要があり、以下の各ステップでそれが示されています。 ### CLI の実行場所 !!! warning "スイッチに CLI をインストールしないでください" - DoubleZero CLI（`doublezero`）は、Arista スイッチではなく **管理サーバーまたは VM** にインストールしてください。 + DoubleZero CLI（`doublezero`）は、Arista スイッチではなく、**管理サーバーまたは VM** にインストールしてください。 ```mermaid flowchart LR @@ -195,15 +195,15 @@ flowchart LR | サービスキーペア | Telemetry Agent | | メトリクスパブリッシャーキーペア | メトリクスパブリッシャーキーペア（コピー） | -### キーとは何か？ +### 鍵とは何ですか？ -キーは安全なログイン資格情報のようなものです： +鍵はセキュアなログイン認証情報のようなものです： -- **サービスキー**：コントリビューターとしてのアイデンティティ - CLI コマンドの実行に使用 -- **メトリクスパブリッシャーキー**：テレメトリデータ送信時のデバイスのアイデンティティ -- **報酬マネージャーキー**：報酬を受け取るウォレットを制御 - [報酬管理](contribute-rewards.md)を参照 +- **サービスキー**: コントリビューターとしてのあなたのアイデンティティ — CLI コマンドの実行に使用 +- **メトリクスパブリッシャーキー**: テレメトリデータ送信のためのデバイスのアイデンティティ +- **報酬マネージャーキー**: どのウォレットが報酬を受け取るかを制御 — コントリビューターリポジトリの[報酬管理](https://github.com/malbeclabs/contributors#rewards-management)を参照 -3 つすべてが暗号キーペア（共有する公開鍵と秘密にする秘密鍵）です。 +3 つすべてが暗号キーペア（共有する公開鍵と、秘密にする秘密鍵）です。 ```mermaid flowchart LR @@ -218,10 +218,16 @@ flowchart LR RK -->|Used for| REW[Rewards Portal
Sets recipient wallets] ``` -!!! note "報酬マネージャーキーは分離して保管してください" - サービスキーとメトリクスパブリッシャーキーは管理サーバーとスイッチに置きます。報酬マネージャーキーはお金の送付先を制御するため、それらのマシンには置かないでください。受取ウォレットを変更するときにのみ必要です。 +!!! note "報酬マネージャーキーは別に保管してください" + サービスキーとメトリクスパブリッシャーキーは管理サーバーとスイッチに配置されます。報酬マネージャーキーはお金の送金先を制御するため、それらのマシンとは別に保管してください。受取ウォレットを変更する場合にのみ必要です。 -### ステップ 2.1：サービスキーの生成 +### ステップ 2.1: コントリビューターリポジトリへのアクセスをリクエスト + +DoubleZero Foundation または Malbec Labs に連絡し、**GitHub ユーザー名**を伝えてください。 + +プライベートリポジトリ [malbeclabs/contributors](https://github.com/malbeclabs/contributors) へのアクセスが付与されます。これを最初に行ってください：このリポジトリにはベースデバイス設定、TCAM および ACL プロファイル、および以下のステップで必要な報酬管理の手順が含まれています。 + +### ステップ 2.2: サービスキーの生成 これは DoubleZero とのやり取りに使用するメインのアイデンティティです。 @@ -229,46 +235,28 @@ flowchart LR doublezero keygen ``` -デフォルトの場所にキーペアが作成されます。出力には **公開鍵** が表示されます — これが DZF と共有するものです。 +デフォルトの場所にキーペアが作成されます。出力に**公開鍵**が表示されます — これは DZF と共有するものです。 -### ステップ 2.2：メトリクスパブリッシャーキーの生成 +### ステップ 2.3: メトリクスパブリッシャーキーの生成 -このキーは Telemetry Agent がメトリクス送信に署名するために使用します。 +この鍵は Telemetry Agent がメトリクス送信に署名するために使用されます。 ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### ステップ 2.3：報酬マネージャーウォレットの作成 - -3 つ目のキーです。報酬を受け取るウォレットを制御しますが、報酬自体を保持しません。 - -自分で管理し署名できる Solana ウォレットを作成し、トランザクション手数料を賄うために約 0.01 SOL をチャージしてください。ハードウェアウォレットが良い選択です。サービスキーを再利用しないでください。 +### ステップ 2.4: サービスキーを DZF に提出 -この時点ではウォレットだけが必要です。実際に報酬を受け取るウォレットの設定は、DZF がこのキーを登録した後の[ステップ 2.7](#step-27-set-your-reward-recipients) で行います。 +DZF に**サービスキーの公開鍵**を送付してください。 -### ステップ 2.4：DZF へのキー提出 - -DoubleZero Foundation または Malbec Labs に連絡し、以下を提供してください： - -1. **サービスキーの公開鍵** -2. **報酬マネージャーの公開鍵**（ステップ 2.3 で作成したもの） -3. **GitHub ユーザー名**（リポジトリアクセス用） - -3 つをまとめて送信してください。DZF はサービスキーと報酬マネージャーキーを別々のオンチェーントランザクションで登録するため、同時に送ることでラウンドトリップを節約できます。 +DZF がオンチェーンに**コントリビューターアカウント**を作成し、完了後に確認の連絡があります。 !!! danger "公開鍵のみ" - 秘密鍵やキーペアファイルを DZF を含む誰にも送信しないでください。DZF が必要とするのは公開鍵のみです。 - -DZF は以下を行います： + 秘密鍵やキーペアファイルを DZF を含む誰にも送らないでください。必要なのは公開鍵のみです。 -- オンチェーンに **コントリビューターアカウント** を作成 -- サービスキーに対して **報酬マネージャーキー** を登録 -- プライベート **コントリビューターリポジトリ** へのアクセスを付与 +### ステップ 2.5: アカウントの確認 -### ステップ 2.5：アカウントの確認 - -確認が取れたら、コントリビューターアカウントが存在することを確認します： +確認が取れたら、コントリビューターアカウントの存在を確認します： ```bash doublezero contributor list @@ -276,46 +264,24 @@ doublezero contributor list リストにあなたのコントリビューターコードが表示されるはずです。 -報酬マネージャーキーも登録されたか確認します： - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` - -`manager` 列に報酬マネージャーの公開鍵が表示されるはずです。空の場合は、DZF にそのステップの完了を依頼してください。 - -### ステップ 2.6：コントリビューターリポジトリへのアクセス - -[malbeclabs/contributors](https://github.com/malbeclabs/contributors) リポジトリには以下が含まれています： - -- 基本デバイス設定 -- TCAM プロファイル -- ACL 設定 -- 追加のセットアップ手順 - -デバイス固有の設定については、そこの手順に従ってください。 +### ステップ 2.6: 報酬管理の設定 -### ステップ 2.7：報酬受取先の設定 +報酬管理は、コントリビューションで獲得した [2Z](glossary.md#2z-token) をどのウォレットがどのような比率で受け取るかを決定します。 -報酬を受け取るウォレットとその比率を指定します。デバイスがトラフィックを処理し始める前にこれを行ってください。報酬はリンクが稼働した瞬間から蓄積されますが、受取ウォレットを指定するまでプロトコルは支払いを行えません。 +ステップ 2.1 でアクセスを取得したコントリビューターリポジトリの[報酬管理](https://github.com/malbeclabs/contributors#rewards-management)に従ってください。 -報酬マネージャーウォレットで [doublezero.xyz/rewards](https://doublezero.xyz/rewards) にサインインし、サービスキーを選択してから、各受取ウォレットとそのパーセンテージを入力します。パーセンテージの合計は 100 にする必要があります。 - -!!! warning "各受取先には 2Z トークンアカウントが必要です" - プロトコルはプレーントークン転送で 2Z を送信し、トークンアカウントを自動作成しません。2Z トークンアカウントを持たない受取ウォレットは、そのエポックの支払いが失敗する原因となります。 - -CLI による代替手段、トークンアカウントの確認方法、結果の検証方法を含む完全なウォークスルーは[報酬管理](contribute-rewards.md)を参照してください。 +!!! note "これは残りのセットアップをブロックしません" + 報酬管理が完了していなくても、デバイスのプロビジョニング、リンクの確立、トラフィックの転送を開始できます。以下のフェーズは報酬管理とは独立して進めてください。 --- -## フェーズ 3：デバイスプロビジョニング +## フェーズ 3: デバイスプロビジョニング ここでは、物理デバイスをブロックチェーンに登録し、インターフェースを設定します。 ### デバイスタイプの理解 -**Edge** — ユーザー接続のみを受け付ける +**Edge** — ユーザー接続のみを受け入れる ```mermaid flowchart LR @@ -359,27 +325,27 @@ flowchart LR H_DZX <-->|DZX Link| HD["DZD (different contributor)"] ``` -| タイプ | 役割 | 使用する場面 | +| タイプ | 機能 | 使用するケース | |------|--------------|-------------| -| **Edge** | ユーザー接続のみを受け付ける | 単一拠点、ユーザー対応のみ | +| **Edge** | ユーザー接続のみを受け入れる | 単一ロケーション、ユーザー向けのみ | | **Transit** | デバイス間のトラフィックを転送 | バックボーン接続、ユーザーなし | -| **Hybrid** | ユーザー接続とバックボーンの両方 | 最も一般的 — すべてを担う | +| **Hybrid** | ユーザー接続とバックボーンの両方 | 最も一般的 — すべてに対応 | -### ステップ 3.1：ロケーションとエクスチェンジの確認 +### ステップ 3.1: ロケーションとエクスチェンジの検索 -デバイスを作成する前に、データセンターのロケーションと最寄りのエクスチェンジのコードを調べます： +デバイスを作成する前に、データセンターのロケーションと最寄りのエクスチェンジのコードを確認します： ```bash -# 利用可能なロケーション（データセンター）を一覧表示 +# 利用可能なロケーション（データセンター）の一覧 doublezero location list -# 利用可能なエクスチェンジ（相互接続ポイント）を一覧表示 +# 利用可能なエクスチェンジ（相互接続ポイント）の一覧 doublezero exchange list ``` -### ステップ 3.2：デバイスのオンチェーン作成 +### ステップ 3.2: デバイスのオンチェーン登録 -デバイスをブロックチェーンに登録します： +ブロックチェーンにデバイスを登録します： ```bash doublezero device create \ @@ -422,16 +388,16 @@ doublezero device list | grep nyc-dz001 | パラメータ | 意味 | |-----------|---------------| | `--code` | デバイスの一意な名前（例：`nyc-dz001`） | -| `--contributor` | コントリビューターコード（DZF より付与） | +| `--contributor` | コントリビューターコード（DZF から付与） | | `--device-type` | `hybrid`、`transit`、または `edge` | | `--location` | `location list` から取得したデータセンターコード | | `--exchange` | `exchange list` から取得した最寄りのエクスチェンジコード | | `--public-ip` | ユーザーがインターネット経由でデバイスに接続するパブリック IP | | `--dz-prefixes` | ユーザー用に割り当てられた IP ブロック | -### ステップ 3.3：必要なループバックインターフェースの作成 +### ステップ 3.3: 必須ループバックインターフェースの作成 -すべてのデバイスには内部ルーティング用に 2 つのループバックインターフェースが必要です： +すべてのデバイスには、内部ルーティング用に 2 つのループバックインターフェースが必要です： ```bash # VPNv4 ループバック @@ -441,15 +407,15 @@ doublezero device interface create Loopback255 --loopback-type vpn doublezero device interface create Loopback256 --loopback-type ipv4 ``` -**期待される出力（各コマンド）：** +**期待される出力（各コマンドごと）：** ``` Signature: 3mNx9K...truncated...8wRt5 ``` -### ステップ 3.4：物理インターフェースの作成 +### ステップ 3.4: 物理インターフェースの作成 -WAN または DZX リンクに使用される物理インターフェースを登録します。これらのインターフェースは、リンクが参照する前にオンチェーンに存在している必要があります。このステップではインターフェースと帯域幅のみを登録し、リンクは後のステップで作成します。 +WAN または DZX リンクに使用される物理インターフェースを登録します。これらのインターフェースは、リンクを作成してそれらを参照する前にオンチェーンに存在している必要があります。このステップではインターフェースと帯域幅のみを登録し、リンクは後のステップで作成します。 ```bash doublezero device interface create \ @@ -469,36 +435,36 @@ doublezero device interface create nyc-dz001 Ethernet1/1 \ Signature: 7pQw2R...truncated...4xKm9 ``` -WAN または DZX リンクのエンドポイントとして使用する各インターフェースについてこれを繰り返します。CYOA および DIA インターフェースは次のステップで別途登録します。 +WAN または DZX リンクのエンドポイントとして使用する各インターフェースについて、これを繰り返します。CYOA および DIA インターフェースは次のステップで別途登録します。 -### ステップ 3.5：CYOA インターフェースの作成（Edge/Hybrid デバイス用） +### ステップ 3.5: CYOA インターフェースの作成（Edge/Hybrid デバイス用） -Hybrid および Edge の DZD では、ユーザーが GRE トンネルを終端する **2 つのパブリック IP アドレス** が必要です。ユーザーはユニキャスト、マルチキャスト、またはその両方で接続でき、どの IP がどの目的に使われるかはユーザーごとにローテーションします。 +Hybrid および Edge の DZD には、ユーザーが GRE トンネルを終端する **2 つのパブリック IP アドレス**が必要です。ユーザーはユニキャスト、マルチキャスト、またはその両方で接続でき、どの IP がどの目的に使用されるかはユーザーごとにローテーションされます。 -両方の IP を `--user-tunnel-endpoint true` で、物理インターフェースまたはループバックに登録する必要があります。これにはデバイス作成時に指定した IP も含まれます — その IP もここで明示的に登録する必要があります。 +両方の IP は、物理インターフェースまたはループバックのいずれかで `--user-tunnel-endpoint true` を付けて登録する必要があります。これにはデバイス作成時に提供した IP も含まれます — その IP もここで明示的に登録する必要があります。 -IP が不足している場合は、DZ プレフィックスの最初の `/32` を 2 つの IP の 1 つとして使用できます。 +IP が制限されている場合は、DZ プレフィックスの最初の `/32` を 2 つの IP のうちの 1 つとして使用できます。 #### CYOA と DIA | タイプ | フラグ | 目的 | |------|------|---------| | DIA | `--interface-dia dia` | ポートをダイレクトインターネットアクセスとしてマーク | -| CYOA | `--interface-cyoa ` | ユーザーがデバイスに GRE トンネルを接続する方法を宣言 | +| CYOA | `--interface-cyoa ` | ユーザーがデバイスに GRE トンネルで接続する方法を宣言 | -CYOA フラグは常に **物理インターフェース**（イーサネットポートまたはポートチャネル）に設定します。ループバックには設定しません。 +CYOA フラグは常に**物理インターフェース**（イーサネットポートまたはポートチャネル）に設定します。ループバックには設定しないでください。 -| CYOA サブタイプ | 使用する場面 | +| CYOA サブタイプ | 使用するケース | |-------------|-------------| | `gre-over-dia` | ユーザーがパブリックインターネット経由で接続。最も一般的。 | | `gre-over-private-peering` | ユーザーがダイレクトクロスコネクトまたはプライベート回線経由で接続 | | `gre-over-public-peering` | ユーザーがインターネットエクスチェンジ（IX）でピアリング | -| `gre-over-fabric` | ユーザーが同一拠点にいてローカルファブリック経由で接続 | +| `gre-over-fabric` | ユーザーが同一施設に設置され、ローカルファブリック経由で接続 | | `gre-over-cable` | 単一の専用ユーザーへの直接ケーブル接続 | -#### シナリオ A：単一物理インターフェース +#### シナリオ A: 単一の物理インターフェース -ISP への物理アップリンクが 1 本。Ethernet1/1 が CYOA および DIA インターフェースで、2 つのパブリック IP の 1 つを持ちます。Loopback100 が 2 つ目のパブリック IP を持ちます。 +ISP への 1 本の物理アップリンク。Ethernet1/1 が CYOA および DIA インターフェースとして 2 つのパブリック IP のうち 1 つを持ちます。Loopback100 が 2 つ目のパブリック IP を持ちます。 ```mermaid flowchart LR @@ -516,4 +482,45 @@ flowchart LR ISP["ISP Router 203.0.113.2/30"] - ISP \ No newline at end of file + ISP -- "10GbE" --- E1 + USERS -. "GRE tunnels" .-> E1 + USERS -. "GRE tunnels" .-> LO +``` + +| インターフェース | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | +|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +| Ethernet1/1 | `gre-over-dia` | `dia` | コントリビューター割り当て IP/サブネット | ポート速度 | 確約レート | `bgp` または `static` | `true` | +| Loopback100 | — | — | パブリック /32 | `0bps` | — | — | `true` | + +シナリオ A に基づくコマンド実行例： +```bash +doublezero device interface create mydzd-nyc01 Ethernet1/1 \ + --interface-cyoa gre-over-dia \ + --interface-dia dia \ + --ip-net 203.0.113.1/30 \ + --bandwidth 10Gbps \ + --cir 1Gbps \ + --routing-mode bgp \ + --user-tunnel-endpoint true + +doublezero device interface create mydzd-nyc01 Loopback100 \ + --ip-net 198.51.100.1/32 \ + --bandwidth 0bps \ + --user-tunnel-endpoint true +``` + +#### シナリオ B: ポートチャネル（LAG） + +DZD が IP を持つポートチャネルを介してアップストリームデバイスに接続します。ポートチャネルが 1 つのパブリック IP を持ち、CYOA エンドポイントとなります。Loopback100 が 2 つ目のパブリック IP を持ちます。 + +```mermaid +flowchart LR + USERS(["End Users"]) + + subgraph SW["Upstream Router / Switch"] + SWPC(["bond0 + 203.0.113.2/30"]) + end + + subgraph DZD["DZD"] + subgraph PC["Port-Channel1 · 203.0.113.1/30 \ No newline at end of file diff --git a/docs/contribute-provisioning.ko.md b/docs/contribute-provisioning.ko.md index cd10150..d36a5ef 100644 --- a/docs/contribute-provisioning.ko.md +++ b/docs/contribute-provisioning.ko.md @@ -1,5 +1,5 @@ --- -description: DoubleZero 디바이스(DZD)를 프로비저닝하고 인터페이스 및 역할을 온체인에 등록하는 단계별 가이드. +description: DoubleZero 디바이스(DZD) 프로비저닝 및 인터페이스와 역할을 온체인에 등록하는 단계별 가이드입니다. --- # 디바이스 프로비저닝 가이드 @@ -8,42 +8,42 @@ description: DoubleZero 디바이스(DZD)를 프로비저닝하고 인터페이 --- -## 전체 구성 개요 +## 전체 구조 이해하기 -이 가이드는 DoubleZero 네트워크가 트래픽을 라우팅할 수 있도록 인프라를 온체인에 등록하는 과정을 안내합니다. 디바이스가 더 완전하게 등록될수록 네트워크에 더 유용합니다. 디바이스의 완전한 온체인 표현은 더 나은 문제 해결, 용량 계획을 가능하게 하며 컨트롤러가 정보에 기반한 결정을 내릴 수 있도록 합니다. 시간이 지남에 따라 컨트롤러가 더 많은 구성 책임을 맡는 것이 목표입니다. +이 가이드는 DoubleZero 네트워크가 트래픽을 라우팅할 수 있도록 인프라를 온체인에 등록하는 과정을 안내합니다. 디바이스가 더 완전하게 등록될수록 네트워크에 더 유용합니다. 디바이스의 완전한 온체인 표현은 더 나은 문제 해결, 용량 계획을 가능하게 하며, 컨트롤러가 정보에 기반한 결정을 내릴 수 있게 합니다. 시간이 지남에 따라 컨트롤러가 더 많은 설정 책임을 맡는 것이 목표입니다. ### 핵심 개념 **인터페이스** -DZD의 인터페이스는 다양한 형태로 제공됩니다: 이더넷 포트, 포트 채널(여러 이더넷 포트로 구성된 LAG), 그리고 루프백. 네트워크에서 역할을 수행하는 각 인터페이스는 프로토콜이 그 기능을 알 수 있도록 적절한 플래그와 함께 온체인에 등록되어야 합니다. +DZD의 인터페이스는 다양한 형태로 제공됩니다: 이더넷 포트, 포트 채널(여러 이더넷 포트로 구성된 LAG), 그리고 루프백. 네트워크에서 역할을 하는 각 인터페이스는 프로토콜이 그 기능을 인식할 수 있도록 적절한 플래그와 함께 온체인에 등록되어야 합니다. -이더넷 포트와 포트 채널은 다음과 같은 역할을 수행할 수 있습니다: +이더넷 포트와 포트 채널은 다음 역할을 수행할 수 있습니다: | 플래그 | 의미 | |------|---------------| -| `--interface-dia dia` | 인터페이스를 직접 인터넷 접속(DIA) 업링크로 표시 | -| `--interface-cyoa ` | 사용자가 이 인터페이스를 통해 GRE 터널을 설정하는 방법을 선언 (예: 공용 인터넷을 통해, 프라이빗 피어링 링크를 통해) | -| `--user-tunnel-endpoint true` | 이 인터페이스는 사용자가 GRE 터널을 종단하는 공용 IP를 보유 | +| `--interface-dia dia` | 인터페이스를 직접 인터넷 접속 업링크로 표시 | +| `--interface-cyoa ` | 사용자가 이 인터페이스를 통해 GRE 터널을 설정하는 방법 선언 (예: 공용 인터넷을 통해, 프라이빗 피어링 링크를 통해) | +| `--user-tunnel-endpoint true` | 이 인터페이스가 사용자가 GRE 터널을 종단하는 공용 IP를 보유 | WAN 또는 DZX 링크에 사용되는 인터페이스는 특정 플래그를 갖지 않으며, 대역폭과 함께 등록된 후 링크 생성 시 참조됩니다. -루프백 인터페이스는 여러 용도로 사용됩니다: +루프백 인터페이스는 여러 목적으로 사용됩니다: | 루프백 | 의미 | |----------|---------------| -| **Loopback100 / 101** | 사용자가 GRE 터널을 종단하는 공용 IP를 보유. `--user-tunnel-endpoint true`로 등록. | -| **Loopback255** (`vpnv4`) | 컨트롤러가 BGP 라우터 ID, VPN-IPv4 피어링(유니캐스트), IS-IS 아이덴티티, 세그먼트 라우팅에 사용되는 IP를 할당할 수 있도록 등록 | -| **Loopback256** (`ipv4`) | 컨트롤러가 IPv4 BGP 피어링(멀티캐스트) 및 MSDP 세션에 사용되는 IP를 할당할 수 있도록 등록 | +| **Loopback100 / 101** | 사용자가 GRE 터널을 종단하는 공용 IP를 보유. `--user-tunnel-endpoint true`로 등록됨. | +| **Loopback255** (`vpnv4`) | 컨트롤러가 BGP 라우터 ID, VPN-IPv4 피어링(유니캐스트), IS-IS ID, 세그먼트 라우팅에 사용되는 IP를 할당할 수 있도록 등록됨 | +| **Loopback256** (`ipv4`) | 컨트롤러가 IPv4 BGP 피어링(멀티캐스트) 및 MSDP 세션에 사용되는 IP를 할당할 수 있도록 등록됨 | **링크** -링크는 인터페이스와 별도로 등록되며, 링크가 참조하려면 인터페이스가 먼저 온체인에 존재해야 합니다. WAN 또는 DZX 링크를 생성할 때 이미 등록된 인터페이스를 링크의 물리적 엔드포인트로 지정합니다. 모든 인터페이스가 링크에 연결되는 것은 아닙니다: DIA, CYOA, 루프백 인터페이스는 링크에 연결되지 않습니다. +링크는 인터페이스와 별도로 등록되며, 링크가 참조하려면 먼저 인터페이스가 온체인에 존재해야 합니다. WAN 또는 DZX 링크를 생성할 때 이미 등록된 인터페이스를 링크의 물리적 엔드포인트로 지정합니다. 모든 인터페이스가 링크에 연결되는 것은 아닙니다: DIA, CYOA, 루프백 인터페이스는 링크에 연결되지 않습니다. | 용어 | 의미 | |------|---------------| -| **WAN 링크** | 자체 DZD 두 대 간의 링크 | -| **DZX 링크** | 자체 DZD와 다른 기여자의 DZD 간의 링크 | +| **WAN 링크** | 자신이 소유한 두 DZD 간의 링크 | +| **DZX 링크** | 자신의 DZD와 다른 기여자의 DZD 간의 링크 | ### 아키텍처 개요 @@ -55,17 +55,17 @@ flowchart TB subgraph Your Infrastructure MGMT[관리 서버
DoubleZero CLI] - subgraph DZD[자체 DZD] + subgraph DZD[내 DZD] CYOA["DIA · CYOA 인터페이스
(사용자 대면 업링크)"] WAN_INTF["WAN 링크 인터페이스"] DZX_INTF["DZX 링크 인터페이스"] LO100["Loopback100/101
(사용자 터널 엔드포인트)"] end - DZD2[자체 다른 DZD] + DZD2[내 다른 DZD] end subgraph Other Contributor - OtherDZD[타 기여자의 DZD] + OtherDZD[상대방 DZD] end USERS["사용자"] @@ -74,29 +74,29 @@ flowchart TB WAN_INTF ---|WAN 링크| DZD2 DZX_INTF ---|DZX 링크| OtherDZD USERS -.|GRE 터널|.-> CYOA - CYOA ---|라우팅 대상| LO100 + CYOA ---|라우팅| LO100 ``` --- ## 1단계: 사전 준비 -디바이스를 프로비저닝하기 전에 물리적 하드웨어 설정과 일부 IP 주소 할당이 필요합니다. +디바이스를 프로비저닝하기 전에 물리적 하드웨어 설치와 일부 IP 주소 할당이 필요합니다. ### 필요 사항 -| 요구사항 | 필요 이유 | +| 요구 사항 | 필요한 이유 | |-------------|-----------------| | **DZD 하드웨어** | Arista 7280CR3A 스위치 ([하드웨어 사양](contribute.md#hardware-requirements) 참조) | -| **랙 공간** | DZD당 1U, 적절한 공기 흐름 필요. [랙 & 전원](contribute.md#rack-power-requirements) 참조 | -| **전원** | 각각이 전체 부하를 단독으로 감당할 수 있는 두 개의 독립적인 전원 공급. [랙 & 전원](contribute.md#rack-power-requirements) 참조 | -| **관리 접근** | 스위치 구성을 위한 SSH/콘솔 접근 | -| **인터넷 연결** | 메트릭 발행 및 컨트롤러로부터 구성 가져오기용 | +| **랙 공간** | DZD당 2U 예약 (현재 1U 사용), 적절한 공기 흐름 필요. [랙 및 전원](contribute.md#rack-power-requirements) 참조 | +| **전원** | 각각 전체 부하를 단독으로 감당할 수 있는 두 개의 독립 전원 공급. [랙 및 전원](contribute.md#rack-power-requirements) 참조 | +| **관리 접근** | 스위치 설정을 위한 SSH/콘솔 접근 | +| **인터넷 연결** | 메트릭 게시 및 컨트롤러에서 설정을 가져오기 위해 필요 | | **공용 IPv4 블록** | DZ 프리픽스 풀을 위한 최소 /29 (아래 참조) | ### DoubleZero CLI 설치 -DoubleZero CLI(`doublezero`)는 프로비저닝 전반에 걸쳐 디바이스 등록, 링크 생성 및 기여 관리에 사용됩니다. **관리 서버 또는 VM**에 설치해야 합니다 — DZD 스위치 자체에는 설치하지 마세요. 스위치에는 Config Agent와 Telemetry Agent만 실행됩니다([4단계](#phase-4-link-establishment-agent-installation)에서 설치). +DoubleZero CLI (`doublezero`)는 프로비저닝 과정 전반에서 디바이스 등록, 링크 생성, 기여 관리에 사용됩니다. **관리 서버 또는 VM**에 설치해야 하며, DZD 스위치 자체에는 설치하지 마세요. 스위치에는 Config Agent와 Telemetry Agent만 실행됩니다([4단계](#phase-4-link-establishment-agent-installation)에서 설치). **Ubuntu / Debian:** ```bash @@ -121,7 +121,7 @@ DZ 프리픽스는 DoubleZero 프로토콜이 IP 할당을 위해 관리하는 ```mermaid flowchart LR - subgraph "자체 /29 블록 (8개 IP)" + subgraph "내 /29 블록 (8개 IP)" IP1["첫 번째 IP
디바이스용
예약"] IP2["IP 2"] IP3["IP 3"] @@ -129,63 +129,63 @@ flowchart LR IP8["IP 8"] end - IP1 -->|할당 대상| LO[Loopback100
자체 DZD] - IP2 -->|할당 대상| U1[사용자 1] - IP3 -->|할당 대상| U2[사용자 2] + IP1 -->|할당됨| LO[Loopback100
내 DZD에] + IP2 -->|할당됨| U1[사용자 1] + IP3 -->|할당됨| U2[사용자 2] ``` **DZ 프리픽스 사용 방법:** -- **첫 번째 IP**: 디바이스용 예약 (Loopback100 인터페이스에 할당) +- **첫 번째 IP**: 디바이스용으로 예약됨 (Loopback100 인터페이스에 할당) - **나머지 IP**: DZD에 연결하는 특정 사용자 유형에 할당: - `IBRLWithAllocatedIP` 사용자 - `EdgeFiltering` 사용자 (향후 사용 사례) - **IBRL 사용자**: 이 풀에서 소비하지 않음 (자체 공용 IP 사용) !!! warning "DZ 프리픽스 규칙" - **이 주소를 다음 용도로 사용할 수 없습니다:** + **다음 용도로 사용할 수 없습니다:** - 자체 네트워크 장비 - - DIA 인터페이스의 포인트-투-포인트 링크 + - DIA 인터페이스의 Point-to-Point 링크 - 관리 인터페이스 - DZ 프로토콜 외부의 모든 인프라 - **요구사항:** + **요구 사항:** - - **전역적으로 라우팅 가능한 (공용)** IPv4 주소여야 함 - - 사설 IP 범위 (10.x, 172.16-31.x, 192.168.x)는 스마트 컨트랙트에서 거부됨 + - **전역적으로 라우팅 가능한(공용)** IPv4 주소여야 합니다 + - 사설 IP 범위(10.x, 172.16-31.x, 192.168.x)는 스마트 컨트랙트에서 거부됩니다 - **최소 크기: /29** (8개 주소), 더 큰 프리픽스 권장 (예: /28, /27) - - 전체 블록이 사용 가능해야 함 — 주소를 미리 할당하지 마세요 + - 전체 블록이 사용 가능해야 합니다 — 주소를 미리 할당하지 마세요 - 자체 장비(DIA 인터페이스 IP, 관리 등)에 주소가 필요한 경우 **별도의 주소 풀**을 사용하세요. + 자체 장비용 주소(DIA 인터페이스 IP, 관리 등)가 필요한 경우 **별도의 주소 풀**을 사용하세요. --- ## 2단계: 계정 설정 -이 단계에서는 네트워크에서 자신과 디바이스를 식별하는 암호화 키를 생성하고, 보상이 지급될 곳을 지정합니다. +이 단계에서는 네트워크에서 자신과 디바이스를 식별하는 암호화 키를 생성하고 보상 관리를 설정합니다. -이 단계에서 세 개의 키가 생성됩니다: 서비스 키, 메트릭 퍼블리셔 키, 보상 관리자 키. 세 개 모두의 공개 키를 [Step 2.4](#step-24-submit-keys-to-dzf)에서 DZF에 함께 제출합니다. [보상 관리](contribute-rewards.md)에서 보상 측면을 자세히 다룹니다. +다음 순서로 진행하는 이유가 있습니다: 먼저 리포지토리 접근 권한 — 리포지토리에 이후 단계에 필요한 지침이 있기 때문이며, 그 다음 키, 그리고 보상 순입니다. 일부 단계에서는 DZF가 조치를 취해야 계속할 수 있으며, 아래 각 항목에 해당 여부가 표시되어 있습니다. ### CLI 실행 위치 !!! warning "스위치에 CLI를 설치하지 마세요" - DoubleZero CLI(`doublezero`)는 Arista 스위치가 아닌 **관리 서버 또는 VM**에 설치해야 합니다. + DoubleZero CLI (`doublezero`)는 Arista 스위치가 아닌 **관리 서버 또는 VM**에 설치해야 합니다. ```mermaid flowchart LR subgraph "관리 서버/VM" CLI[DoubleZero CLI] - KEYS[키 쌍] + KEYS[내 키 쌍] end - subgraph "자체 DZD 스위치" + subgraph "내 DZD 스위치" CA[Config Agent] TA[Telemetry Agent] end CLI -->|디바이스, 링크 생성| BC[블록체인] - CA -->|구성 가져오기| CTRL[컨트롤러] + CA -->|설정 가져오기| CTRL[컨트롤러] TA -->|메트릭 제출| BC ``` @@ -197,41 +197,47 @@ flowchart LR ### 키란 무엇인가? -키를 안전한 로그인 자격 증명으로 생각하세요: +키는 안전한 로그인 자격 증명과 같습니다: -- **서비스 키**: 기여자 아이덴티티 - CLI 명령 실행에 사용 -- **메트릭 퍼블리셔 키**: 텔레메트리 데이터 제출을 위한 디바이스 아이덴티티 -- **보상 관리자 키**: 보상을 받을 지갑을 제어 - [보상 관리](contribute-rewards.md) 참조 +- **서비스 키**: 기여자 신원 - CLI 명령 실행에 사용 +- **메트릭 퍼블리셔 키**: 텔레메트리 데이터 제출을 위한 디바이스 신원 +- **보상 관리자 키**: 보상을 받을 지갑을 제어 - 기여자 리포지토리의 [보상 관리](https://github.com/malbeclabs/contributors#rewards-management) 참조 -세 가지 모두 암호화 키 쌍(공유하는 공개 키와 비밀로 유지하는 개인 키)입니다. +세 가지 모두 암호화 키 쌍입니다 (공유하는 공개 키와 비밀로 유지하는 개인 키). ```mermaid flowchart LR - subgraph "키 목록" + subgraph "내 키" SK[서비스 키
~/.config/solana/id.json] MK[메트릭 퍼블리셔 키
~/.config/doublezero/metrics-publisher.json] RK[보상 관리자 키
오프라인 보관] end SK -->|사용 용도| CLI[CLI 명령
doublezero device create
doublezero link create] - MK -->|사용 용도| TEL[Telemetry Agent
메트릭을 온체인에 제출] + MK -->|사용 용도| TEL[Telemetry Agent
온체인 메트릭 제출] RK -->|사용 용도| REW[보상 포털
수신 지갑 설정] ``` -!!! note "보상 관리자 키를 별도로 보관하세요" - 서비스 키와 메트릭 퍼블리셔 키는 관리 서버와 스위치에 저장됩니다. 보상 관리자 키는 자금이 전송되는 곳을 제어하므로 해당 머신에서 분리하여 보관하세요. 수신 지갑을 변경할 때만 필요합니다. +!!! note "보상 관리자 키는 별도로 보관하세요" + 서비스 키와 메트릭 퍼블리셔 키는 관리 서버와 스위치에 보관됩니다. 보상 관리자 키는 자금이 어디로 가는지를 제어하므로, 해당 장비에서 분리하여 보관하세요. 수신 지갑을 변경할 때만 필요합니다. -### Step 2.1: 서비스 키 생성 +### 2.1단계: 기여자 리포지토리 접근 요청 -DoubleZero와 상호작용하기 위한 기본 아이덴티티입니다. +DoubleZero Foundation 또는 Malbec Labs에 연락하여 **GitHub 사용자 이름**을 제공하세요. + +비공개 [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 리포지토리에 대한 접근 권한이 부여됩니다. 이것을 먼저 하세요: 리포지토리에 기본 디바이스 설정, TCAM 및 ACL 프로파일, 그리고 아래 단계에서 필요한 보상 관리 지침이 있습니다. + +### 2.2단계: 서비스 키 생성 + +이것은 DoubleZero와 상호작용하기 위한 주요 신원입니다. ```bash doublezero keygen ``` -기본 위치에 키 쌍이 생성됩니다. 출력에 **공개 키**가 표시됩니다 - 이것이 DZF와 공유할 키입니다. +이 명령은 기본 위치에 키 쌍을 생성합니다. 출력에 **공개 키**가 표시됩니다 — 이것이 DZF와 공유할 키입니다. -### Step 2.2: 메트릭 퍼블리셔 키 생성 +### 2.3단계: 메트릭 퍼블리셔 키 생성 이 키는 Telemetry Agent가 메트릭 제출에 서명할 때 사용됩니다. @@ -239,83 +245,43 @@ doublezero keygen doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Step 2.3: 보상 관리자 지갑 생성 - -세 번째 키입니다. 보상을 받을 지갑을 제어하며, 보상 자체를 보유하지는 않습니다. - -자신이 통제하고 서명할 수 있는 Solana 지갑을 생성한 후, 트랜잭션 수수료를 위해 약 0.01 SOL을 충전합니다. 하드웨어 지갑이 좋은 선택입니다. 서비스 키를 재사용하지 마세요. - -이 시점에서는 지갑만 필요합니다. 실제로 보상을 받을 지갑은 DZF가 이 키를 등록한 후 [Step 2.7](#step-27-set-your-reward-recipients)에서 설정합니다. - -### Step 2.4: DZF에 키 제출 +### 2.4단계: 서비스 키를 DZF에 제출 -DoubleZero Foundation 또는 Malbec Labs에 연락하여 다음을 제공합니다: +DZF에 **서비스 키 공개 키**를 보내세요. -1. **서비스 키 공개 키** -2. **보상 관리자 공개 키** (Step 2.3에서 생성) -3. **GitHub 사용자명** (저장소 접근용) +DZF가 온체인에 **기여자 계정**을 생성하고 완료 시 확인합니다. -세 가지를 함께 전송합니다. DZF는 서비스 키와 보상 관리자 키를 별도의 온체인 트랜잭션으로 등록하므로, 동시에 보내면 왕복 시간을 절약할 수 있습니다. +!!! danger "공개 키만 제공하세요" + 개인 키나 키 쌍 파일을 DZF를 포함하여 누구에게도 보내지 마세요. 공개 키만 필요합니다. -!!! danger "공개 키만 제출" - DZF를 포함하여 누구에게도 개인 키나 키 쌍 파일을 절대 보내지 마세요. DZF는 공개 키만 필요합니다. +### 2.5단계: 계정 확인 -DZF는 다음을 수행합니다: - -- 온체인에 **기여자 계정** 생성 -- 서비스 키에 대해 **보상 관리자 키** 등록 -- 프라이빗 **기여자 저장소**에 대한 접근 권한 부여 - -### Step 2.5: 계정 확인 - -확인을 받은 후 기여자 계정이 존재하는지 확인합니다: +확인을 받으면 기여자 계정이 존재하는지 확인합니다: ```bash doublezero contributor list ``` -목록에서 기여자 코드가 표시되어야 합니다. - -보상 관리자 키도 등록되었는지 확인합니다: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` - -`manager` 열에 보상 관리자 공개 키가 표시되어야 합니다. 비어 있으면 DZF에 해당 단계를 완료하도록 요청하세요. - -### Step 2.6: 기여자 저장소 접근 - -[malbeclabs/contributors](https://github.com/malbeclabs/contributors) 저장소에는 다음이 포함되어 있습니다: - -- 기본 디바이스 구성 -- TCAM 프로파일 -- ACL 구성 -- 추가 설정 지침 +목록에서 자신의 기여자 코드를 확인할 수 있어야 합니다. -디바이스별 구성에 대해서는 해당 저장소의 지침을 따르세요. +### 2.6단계: 보상 관리 설정 -### Step 2.7: 보상 수신자 설정 +보상 관리는 기여가 획득한 [2Z](glossary.md#2z-token)를 어떤 지갑이 어떤 비율로 받을지를 결정합니다. -보상을 받을 지갑과 비율을 지정합니다. 디바이스가 트래픽을 전달하기 전에 이 작업을 수행하세요. 보상은 링크가 활성화되는 순간부터 쌓이지만, 수신 지갑을 지정할 때까지 프로토콜이 보상을 지급할 수 없습니다. +2.1단계에서 접근 권한을 얻은 기여자 리포지토리의 [보상 관리](https://github.com/malbeclabs/contributors#rewards-management)를 따르세요. -보상 관리자 지갑으로 [doublezero.xyz/rewards](https://doublezero.xyz/rewards)에 로그인하고, 서비스 키를 선택한 다음, 각 수신 지갑과 비율을 입력합니다. 비율의 합계는 100이어야 합니다. - -!!! warning "각 수신자에게 2Z 토큰 계정이 필요합니다" - 프로토콜은 일반 토큰 전송으로 2Z를 보내며 토큰 계정을 대신 생성하지 않습니다. 2Z 토큰 계정이 없는 수신 지갑은 해당 에포크의 지급 실패를 초래합니다. - -CLI 대안, 토큰 계정 확인 방법, 결과 검증을 포함한 전체 안내는 [보상 관리](contribute-rewards.md)를 참조하세요. +!!! note "나머지 설정을 차단하지 않습니다" + 이것이 완료되지 않아도 디바이스 프로비저닝, 링크 설정 및 트래픽 전달을 시작할 수 있으므로, 아래 단계들은 이것과 독립적으로 진행하세요. --- ## 3단계: 디바이스 프로비저닝 -이제 물리적 디바이스를 블록체인에 등록하고 인터페이스를 구성합니다. +이제 물리적 디바이스를 블록체인에 등록하고 인터페이스를 설정합니다. ### 디바이스 유형 이해하기 -**Edge** — 사용자 연결만 수용 +**Edge** — 사용자 연결만 수락 ```mermaid flowchart LR @@ -330,7 +296,7 @@ flowchart LR E_DZX <-->|DZX 링크| ED["DZD (다른 기여자)"] ``` -**Transit** — 디바이스 간 트래픽 전달, 사용자 연결 없음 +**Transit** — 디바이스 간 트래픽 이동, 사용자 연결 없음 ```mermaid flowchart LR @@ -338,11 +304,11 @@ flowchart LR T_WAN["WAN 링크 인터페이스"] T_DZX["DZX 링크 인터페이스"] end - T_WAN <-->|WAN 링크| T2["DZD (동일 기여자)"] + T_WAN <-->|WAN 링크| T2["DZD (같은 기여자)"] T_DZX <-->|DZX 링크| TD["DZD (다른 기여자)"] ``` -**Hybrid** — 사용자 연결과 백본 모두, 가장 일반적 +**Hybrid** — 사용자 연결과 백본, 가장 일반적 ```mermaid flowchart LR @@ -355,29 +321,29 @@ flowchart LR H_CYOA --- H_TUN end HU["사용자"] -.|GRE 터널|.-> H_CYOA - H_WAN <-->|WAN 링크| H2["DZD (동일 기여자)"] + H_WAN <-->|WAN 링크| H2["DZD (같은 기여자)"] H_DZX <-->|DZX 링크| HD["DZD (다른 기여자)"] ``` -| 유형 | 역할 | 사용 시기 | +| 유형 | 기능 | 사용 시기 | |------|--------------|-------------| -| **Edge** | 사용자 연결만 수용 | 단일 위치, 사용자 대면 전용 | -| **Transit** | 디바이스 간 트래픽 전달 | 백본 연결, 사용자 없음 | -| **Hybrid** | 사용자 연결과 백본 모두 | 가장 일반적 - 모든 기능 수행 | +| **Edge** | 사용자 연결만 수락 | 단일 위치, 사용자 대면 전용 | +| **Transit** | 디바이스 간 트래픽 이동 | 백본 연결, 사용자 없음 | +| **Hybrid** | 사용자 연결과 백본 모두 | 가장 일반적 — 모든 기능 수행 | -### Step 3.1: 위치 및 익스체인지 조회 +### 3.1단계: 위치와 교환소 찾기 -디바이스를 생성하기 전에 데이터 센터 위치와 가장 가까운 익스체인지의 코드를 조회합니다: +디바이스를 생성하기 전에 데이터센터 위치와 가장 가까운 교환소 코드를 조회하세요: ```bash -# 사용 가능한 위치 (데이터 센터) 목록 +# 사용 가능한 위치(데이터센터) 목록 doublezero location list -# 사용 가능한 익스체인지 (상호연결 지점) 목록 +# 사용 가능한 교환소(상호연결 지점) 목록 doublezero exchange list ``` -### Step 3.2: 디바이스를 온체인에 생성 +### 3.2단계: 디바이스 온체인 생성 블록체인에 디바이스를 등록합니다: @@ -411,25 +377,25 @@ doublezero device create \ Signature: 4vKz8H...truncated...7xPq2 ``` -디바이스가 생성되었는지 확인합니다: +디바이스가 생성되었는지 확인: ```bash doublezero device list | grep nyc-dz001 ``` -**매개변수 설명:** +**파라미터 설명:** -| 매개변수 | 의미 | +| 파라미터 | 의미 | |-----------|---------------| | `--code` | 디바이스의 고유 이름 (예: `nyc-dz001`) | | `--contributor` | 기여자 코드 (DZF에서 제공) | | `--device-type` | `hybrid`, `transit`, 또는 `edge` | -| `--location` | `location list`에서 확인한 데이터 센터 코드 | -| `--exchange` | `exchange list`에서 확인한 가장 가까운 익스체인지 코드 | +| `--location` | `location list`에서 가져온 데이터센터 코드 | +| `--exchange` | `exchange list`에서 가져온 가장 가까운 교환소 코드 | | `--public-ip` | 사용자가 인터넷을 통해 디바이스에 연결하는 공용 IP | | `--dz-prefixes` | 사용자를 위해 할당된 IP 블록 | -### Step 3.3: 필수 루프백 인터페이스 생성 +### 3.3단계: 필수 루프백 인터페이스 생성 모든 디바이스에는 내부 라우팅을 위한 두 개의 루프백 인터페이스가 필요합니다: @@ -441,15 +407,15 @@ doublezero device interface create Loopback255 --loopback-type vpn doublezero device interface create Loopback256 --loopback-type ipv4 ``` -**예상 출력 (각 명령에 대해):** +**예상 출력 (각 명령별):** ``` Signature: 3mNx9K...truncated...8wRt5 ``` -### Step 3.4: 물리적 인터페이스 생성 +### 3.4단계: 물리적 인터페이스 생성 -WAN 또는 DZX 링크에 사용될 물리적 인터페이스를 등록합니다. 이 인터페이스는 링크가 참조하려면 먼저 온체인에 존재해야 합니다. 이 단계에서는 인터페이스와 대역폭만 등록하며, 링크는 이후 단계에서 생성됩니다. +WAN 또는 DZX 링크에 사용될 물리적 인터페이스를 등록합니다. 이 인터페이스들은 링크를 참조하는 링크를 생성하기 전에 온체인에 존재해야 합니다. 이 단계에서는 인터페이스와 대역폭만 등록하며, 링크는 이후 단계에서 생성됩니다. ```bash doublezero device interface create \ @@ -469,8 +435,33 @@ doublezero device interface create nyc-dz001 Ethernet1/1 \ Signature: 7pQw2R...truncated...4xKm9 ``` -WAN 또는 DZX 링크 엔드포인트로 사용될 각 인터페이스에 대해 이 작업을 반복합니다. CYOA 및 DIA 인터페이스는 다음 단계에서 별도로 등록됩니다. +WAN 또는 DZX 링크 엔드포인트로 사용될 각 인터페이스에 대해 이 과정을 반복합니다. CYOA 및 DIA 인터페이스는 다음 단계에서 별도로 등록됩니다. + +### 3.5단계: CYOA 인터페이스 생성 (Edge/Hybrid 디바이스용) + +Hybrid 및 Edge DZD에는 사용자가 GRE 터널을 종단하는 **두 개의 공용 IP 주소**가 필요합니다. 사용자는 유니캐스트, 멀티캐스트, 또는 둘 다를 통해 연결할 수 있으며, 어떤 IP가 어떤 용도로 사용되는지는 사용자별로 순환됩니다. + +두 IP 모두 `--user-tunnel-endpoint true`로 등록해야 하며, 물리적 인터페이스 또는 루프백에 등록할 수 있습니다. 디바이스 생성 시 제공한 IP도 포함되며, 해당 IP는 여기서 명시적으로 등록해야 합니다. + +IP가 부족한 경우, DZ 프리픽스의 첫 번째 `/32`를 두 IP 중 하나로 사용할 수 있습니다. + +#### CYOA와 DIA + +| 유형 | 플래그 | 목적 | +|------|------|---------| +| DIA | `--interface-dia dia` | 포트를 직접 인터넷 접속으로 표시 | +| CYOA | `--interface-cyoa ` | 사용자가 디바이스에 GRE 터널을 연결하는 방법 선언 | + +CYOA 플래그는 항상 **물리적 인터페이스**(이더넷 포트 또는 포트 채널)에 설정됩니다. 루프백에는 절대 설정하지 마세요. + +| CYOA 서브타입 | 사용 시기 | +|-------------|-------------| +| `gre-over-dia` | 사용자가 공용 인터넷을 통해 연결. 가장 일반적. | +| `gre-over-private-peering` | 사용자가 직접 크로스 커넥트 또는 전용 회선을 통해 연결 | +| `gre-over-public-peering` | 사용자가 인터넷 교환(IX)에서 피어링 | +| `gre-over-fabric` | 사용자가 같은 위치에서 로컬 패브릭을 통해 연결 | +| `gre-over-cable` | 단일 전용 사용자에 대한 직접 케이블 연결 | -### Step 3.5: CYOA 인터페이스 생성 (Edge/Hybrid 디바이스용) +#### 시나리오 A: 단일 물리적 인터페이스 -Hybrid 및 Edge DZD에는 사용자가 GRE 터널을 종단하는 **두 개의 공용 IP 주소**가 필요합니다. 사용자는 유니캐스트, 멀티캐스트, 또는 둘 다를 \ No newline at end of file +ISP로의 단일 물리적 업링크. Ethernet1/1이 CYOA 및 DIA 인터페이스이며 두 공 \ No newline at end of file diff --git a/docs/contribute-provisioning.pt.md b/docs/contribute-provisioning.pt.md index e5a79a6..687b7a1 100644 --- a/docs/contribute-provisioning.pt.md +++ b/docs/contribute-provisioning.pt.md @@ -2,43 +2,43 @@ description: Guia passo a passo para provisionar um Dispositivo DoubleZero (DZD) e registrar suas interfaces e funções on-chain. --- -# Guia de Provisionamento de Dispositivos +# Guia de Provisionamento de Dispositivo -Este guia orienta você no provisionamento de um Dispositivo DoubleZero (DZD) do início ao fim. Cada fase corresponde ao [Checklist de Integração](contribute-overview.md#onboarding-checklist). +Este guia orienta você por todo o provisionamento de um Dispositivo DoubleZero (DZD) do início ao fim. Cada fase corresponde à [Lista de Verificação de Integração](contribute-overview.md#onboarding-checklist). --- -## Como Tudo Se Encaixa +## Como Tudo se Encaixa -Este guia orienta você no registro da sua infraestrutura on-chain para que a rede DoubleZero possa rotear tráfego através dela. Quanto mais completamente seu dispositivo estiver registrado, mais útil ele será para a rede. Uma representação on-chain completa do seu dispositivo permite melhor resolução de problemas, planejamento de capacidade e permite que o controlador tome decisões informadas. Com o tempo, o objetivo é que o controlador assuma mais responsabilidade de configuração. +Este guia orienta você a registrar sua infraestrutura on-chain para que a rede DoubleZero possa rotear tráfego por ela. Quanto mais completo for o registro do seu dispositivo, mais útil ele será para a rede. Uma representação on-chain completa do seu dispositivo permite melhor diagnóstico de problemas, planejamento de capacidade e permite que o controlador tome decisões informadas. Com o tempo, o objetivo é que o controlador assuma mais responsabilidade de configuração. ### Conceitos-chave **Interfaces** -As interfaces em um DZD vêm em diferentes formas: portas Ethernet, port channels (LAGs compostos por múltiplas portas Ethernet) e loopbacks. Cada interface que desempenha um papel na rede precisa ser registrada on-chain com as flags apropriadas para que o protocolo saiba o que ela faz. +As interfaces em um DZD apresentam diferentes formas: portas Ethernet, canais de porta (LAGs compostos por múltiplas portas Ethernet) e loopbacks. Cada interface que desempenha uma função na rede precisa ser registrada on-chain com as flags apropriadas para que o protocolo saiba o que ela faz. -Portas Ethernet e port channels podem desempenhar as seguintes funções: +Portas Ethernet e canais de porta podem desempenhar as seguintes funções: | Flag | O que significa | |------|-----------------| -| `--interface-dia dia` | Marca a interface como uplink de acesso direto à internet | -| `--interface-cyoa ` | Declara como os usuários estabelecem túneis GRE através desta interface (ex: pela internet pública, via link de peering privado) | -| `--user-tunnel-endpoint true` | Esta interface possui um IP público no qual os usuários terminam túneis GRE | +| `--interface-dia dia` | Marca a interface como o uplink de acesso direto à internet | +| `--interface-cyoa ` | Declara como os usuários estabelecem túneis GRE por esta interface (ex.: pela internet pública, via um link de peering privado) | +| `--user-tunnel-endpoint true` | Esta interface carrega um IP público no qual os usuários terminam túneis GRE | -Interfaces usadas para links WAN ou DZX não possuem uma flag específica — elas são registradas com sua largura de banda e então referenciadas quando o link é criado. +Interfaces usadas para links WAN ou DZX não carregam uma flag específica; elas são registradas com sua largura de banda e então referenciadas quando o link é criado. -Interfaces loopback servem a diversos propósitos: +Interfaces loopback servem a vários propósitos: | Loopback | O que significa | |----------|-----------------| -| **Loopback100 / 101** | Possuem IPs públicos nos quais os usuários terminam túneis GRE. Registrados com `--user-tunnel-endpoint true`. | -| **Loopback255** (`vpnv4`) | Registrado para que o controlador possa atribuir um IP usado para router ID BGP, peering VPN-IPv4 (unicast), identidade IS-IS e segment routing | -| **Loopback256** (`ipv4`) | Registrado para que o controlador possa atribuir um IP usado para peering BGP IPv4 (multicast) e sessões MSDP | +| **Loopback100 / 101** | Carregam IPs públicos nos quais os usuários terminam túneis GRE. Registradas com `--user-tunnel-endpoint true`. | +| **Loopback255** (`vpnv4`) | Registrada para que o controlador possa atribuir um IP usado para router ID BGP, peering VPN-IPv4 (unicast), identidade IS-IS e segment routing | +| **Loopback256** (`ipv4`) | Registrada para que o controlador possa atribuir um IP usado para peering BGP IPv4 (multicast) e sessões MSDP | **Links** -Links são registrados separadamente das interfaces, e as interfaces devem existir on-chain antes que um link possa referenciá-las. Quando você cria um link WAN ou DZX, você especifica uma interface já registrada como o endpoint físico do link. Nem todas as interfaces estão vinculadas a um link: interfaces DIA, CYOA e loopback não são conectadas a um link. +Os links são registrados separadamente das interfaces, e as interfaces devem existir on-chain antes que um link possa referenciá-las. Quando você cria um link WAN ou DZX, você especifica uma interface já registrada como o endpoint físico do link. Nem todas as interfaces estão vinculadas a um link: interfaces DIA, CYOA e loopback não estão conectadas a um link. | Termo | O que significa | |-------|-----------------| @@ -50,11 +50,11 @@ Links são registrados separadamente das interfaces, e as interfaces devem exist ```mermaid flowchart TB subgraph Onchain - SC[DoubleZero Ledger] + SC[Ledger DoubleZero] end subgraph Your Infrastructure - MGMT[Servidor de Gerenciamento
DoubleZero CLI] + MGMT[Servidor de Gerenciamento
CLI DoubleZero] subgraph DZD[Seu DZD] CYOA["Interface DIA · CYOA
(uplink voltado ao usuário)"] WAN_INTF["Interface de link WAN"] @@ -88,15 +88,15 @@ Antes de provisionar um dispositivo, você precisa ter o hardware físico config | Requisito | Por Que É Necessário | |-----------|----------------------| | **Hardware DZD** | Switch Arista 7280CR3A (veja [especificações de hardware](contribute.md#hardware-requirements)) | -| **Espaço em Rack** | 1U por DZD, com fluxo de ar adequado. Veja [Rack e Energia](contribute.md#rack-power-requirements) | -| **Energia** | Duas alimentações independentes, cada uma capaz de suportar toda a carga sozinha. Veja [Rack e Energia](contribute.md#rack-power-requirements) | +| **Espaço em Rack** | 2U reservados por DZD (1U em uso atualmente), com fluxo de ar adequado. Veja [Rack & Energia](contribute.md#rack-power-requirements) | +| **Energia** | Duas alimentações independentes, cada uma capaz de suportar toda a carga sozinha. Veja [Rack & Energia](contribute.md#rack-power-requirements) | | **Acesso de Gerenciamento** | Acesso SSH/console para configurar o switch | -| **Conectividade com a Internet** | Para publicação de métricas e para buscar configuração do controlador | +| **Conectividade com a Internet** | Para publicação de métricas e busca de configuração do controlador | | **Bloco IPv4 Público** | Mínimo /29 para o pool de prefixos DZ (veja abaixo) | -### Instalar o CLI DoubleZero +### Instale a CLI DoubleZero -O CLI DoubleZero (`doublezero`) é usado durante todo o provisionamento para registrar dispositivos, criar links e gerenciar sua contribuição. Ele deve ser instalado em um **servidor de gerenciamento ou VM** — não no switch DZD em si. O switch executa apenas o Config Agent e o Telemetry Agent (instalados na [Fase 4](#fase-4-estabelecimento-de-links-instalação-de-agentes)). +A CLI DoubleZero (`doublezero`) é usada durante todo o provisionamento para registrar dispositivos, criar links e gerenciar sua contribuição. Ela deve ser instalada em um **servidor de gerenciamento ou VM** — não no switch DZD em si. O switch executa apenas o Config Agent e o Telemetry Agent (instalados na [Fase 4](#fase-4-estabelecimento-de-links-instalacao-de-agentes)). **Ubuntu / Debian:** ```bash @@ -137,24 +137,24 @@ flowchart LR **Como os prefixos DZ são usados:** - **Primeiro IP**: Reservado para seu dispositivo (atribuído à interface Loopback100) -- **IPs restantes**: Alocados para tipos específicos de usuários conectando ao seu DZD: +- **IPs restantes**: Alocados para tipos específicos de usuários que se conectam ao seu DZD: - Usuários `IBRLWithAllocatedIP` - Usuários `EdgeFiltering` (caso de uso futuro) - **Usuários IBRL**: NÃO consomem deste pool (eles usam seu próprio IP público) !!! warning "Regras do Prefixo DZ" - **Você NÃO PODE usar estes endereços para:** + **Você NÃO PODE usar esses endereços para:** - Seus próprios equipamentos de rede - - Links ponto a ponto em interfaces DIA + - Links ponto-a-ponto em interfaces DIA - Interfaces de gerenciamento - Qualquer infraestrutura fora do protocolo DZ **Requisitos:** - Devem ser endereços IPv4 **globalmente roteáveis (públicos)** - - Faixas de IP privado (10.x, 172.16-31.x, 192.168.x) são rejeitadas pelo smart contract - - **Tamanho mínimo: /29** (8 endereços), prefixos maiores são preferíveis (ex: /28, /27) + - Faixas de IP privadas (10.x, 172.16-31.x, 192.168.x) são rejeitadas pelo contrato inteligente + - **Tamanho mínimo: /29** (8 endereços), prefixos maiores são preferidos (ex.: /28, /27) - O bloco inteiro deve estar disponível — não pré-aloque nenhum endereço Se você precisar de endereços para seus próprios equipamentos (IPs de interface DIA, gerenciamento, etc.), use um **pool de endereços separado**. @@ -163,19 +163,19 @@ flowchart LR ## Fase 2: Configuração da Conta -Nesta fase, você cria as chaves criptográficas que identificam você e seus dispositivos na rede, e define onde suas recompensas devem ser pagas. +Nesta fase, você cria as chaves criptográficas que identificam você e seus dispositivos na rede, e configura o gerenciamento de recompensas. -Três chaves resultam desta fase: uma chave de serviço, uma chave de publicador de métricas e uma chave de gerenciador de recompensas. Envie as chaves públicas de todas as três para a DZF juntas no [Passo 2.4](#passo-24-enviar-chaves-para-a-dzf). [Gerenciamento de Recompensas](contribute-rewards.md) cobre o lado das recompensas em detalhes. +As etapas são executadas nesta ordem por um motivo: acesso ao repositório primeiro, porque o repositório contém as instruções para as etapas posteriores, depois suas chaves, depois as recompensas. Algumas etapas precisam que a DZF atue antes que você possa continuar, e cada uma abaixo indica quando isso ocorre. -### Onde Executar o CLI +### Onde Executar a CLI -!!! warning "NÃO instale o CLI no seu switch" - O CLI DoubleZero (`doublezero`) deve ser instalado em um **servidor de gerenciamento ou VM**, não no seu switch Arista. +!!! warning "NÃO instale a CLI no seu switch" + A CLI DoubleZero (`doublezero`) deve ser instalada em um **servidor de gerenciamento ou VM**, não no seu switch Arista. ```mermaid flowchart LR subgraph "Servidor de Gerenciamento/VM" - CLI[DoubleZero CLI] + CLI[CLI DoubleZero] KEYS[Seus Pares de Chaves] end @@ -193,15 +193,15 @@ Três chaves resultam desta fase: uma chave de serviço, uma chave de publicador |---------------------------------------|---------------------| | CLI `doublezero` | Config Agent | | Seu par de chaves de serviço | Telemetry Agent | - | Seu par de chaves de publicador de métricas | Par de chaves de publicador de métricas (cópia) | + | Seu par de chaves do publicador de métricas | Par de chaves do publicador de métricas (cópia) | ### O Que São Chaves? -Pense nas chaves como credenciais seguras de login: +Pense nas chaves como credenciais de login seguras: -- **Chave de Serviço**: Sua identidade de contribuidor - usada para executar comandos do CLI -- **Chave de Publicador de Métricas**: A identidade do seu dispositivo para enviar dados de telemetria -- **Chave de Gerenciador de Recompensas**: Controla quais carteiras recebem suas recompensas - veja [Gerenciamento de Recompensas](contribute-rewards.md) +- **Chave de Serviço**: Sua identidade como contribuidor - usada para executar comandos da CLI +- **Chave do Publicador de Métricas**: A identidade do seu dispositivo para enviar dados de telemetria +- **Chave do Gerenciador de Recompensas**: Controla quais carteiras recebem suas recompensas - veja [Gerenciamento de Recompensas](https://github.com/malbeclabs/contributors#rewards-management) no repositório de contribuidores Todas as três são pares de chaves criptográficas (uma chave pública que você compartilha, uma chave privada que você mantém em segredo). @@ -209,19 +209,25 @@ Todas as três são pares de chaves criptográficas (uma chave pública que voc flowchart LR subgraph "Suas Chaves" SK[Chave de Serviço
~/.config/solana/id.json] - MK[Chave de Publicador de Métricas
~/.config/doublezero/metrics-publisher.json] - RK[Chave de Gerenciador de Recompensas
manter offline] + MK[Chave do Publicador de Métricas
~/.config/doublezero/metrics-publisher.json] + RK[Chave do Gerenciador de Recompensas
manter offline] end - SK -->|Usada para| CLI[Comandos CLI
doublezero device create
doublezero link create] - MK -->|Usada para| TEL[Telemetry Agent
Envia métricas onchain] + SK -->|Usada para| CLI[Comandos da CLI
doublezero device create
doublezero link create] + MK -->|Usada para| TEL[Telemetry Agent
Envia métricas on-chain] RK -->|Usada para| REW[Portal de Recompensas
Define carteiras destinatárias] ``` -!!! note "Mantenha a chave de gerenciador de recompensas separada" - A chave de serviço e a chave de publicador de métricas ficam no seu servidor de gerenciamento e no switch. A chave de gerenciador de recompensas controla para onde seu dinheiro vai, então mantenha-a fora dessas máquinas. Ela só é necessária quando você altera suas carteiras destinatárias. +!!! note "Mantenha a chave do gerenciador de recompensas separada" + A chave de serviço e a chave do publicador de métricas ficam no seu servidor de gerenciamento e no switch. A chave do gerenciador de recompensas controla para onde seu dinheiro vai, então mantenha-a fora dessas máquinas. Ela só é necessária quando você altera suas carteiras destinatárias. -### Passo 2.1: Gerar Sua Chave de Serviço +### Etapa 2.1: Solicitar Acesso ao Repositório de Contribuidores + +Entre em contato com a DoubleZero Foundation ou a Malbec Labs e forneça seu **nome de usuário do GitHub**. + +Eles concedem acesso ao repositório privado [malbeclabs/contributors](https://github.com/malbeclabs/contributors). Faça isso primeiro: o repositório contém a configuração base do dispositivo, os perfis TCAM e ACL, e as instruções de gerenciamento de recompensas que você precisará nas etapas seguintes. + +### Etapa 2.2: Gerar Sua Chave de Serviço Esta é sua identidade principal para interagir com o DoubleZero. @@ -231,81 +237,41 @@ doublezero keygen Isso cria um par de chaves no local padrão. A saída mostra sua **chave pública** - é isso que você compartilhará com a DZF. -### Passo 2.2: Gerar Sua Chave de Publicador de Métricas +### Etapa 2.3: Gerar Sua Chave do Publicador de Métricas -Esta chave é usada pelo Telemetry Agent para assinar envios de métricas. +Esta chave é usada pelo Telemetry Agent para assinar os envios de métricas. ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### Passo 2.3: Criar Sua Carteira de Gerenciador de Recompensas - -Esta é a terceira chave. Ela controla quais carteiras recebem suas recompensas, e nunca as retém. - -Crie uma carteira Solana que você controle e possa assinar, depois financie-a com cerca de 0,01 SOL para cobrir taxas de transação. Uma carteira de hardware é uma boa escolha. Não reutilize sua chave de serviço. +### Etapa 2.4: Enviar Sua Chave de Serviço à DZF -Você só precisa da carteira neste momento. Você definirá as carteiras que realmente recebem suas recompensas no [Passo 2.7](#passo-27-definir-seus-destinatários-de-recompensa), depois que a DZF tiver registrado esta chave. +Envie à DZF a **chave pública da sua chave de serviço**. -### Passo 2.4: Enviar Chaves para a DZF - -Entre em contato com a DoubleZero Foundation ou Malbec Labs e forneça: - -1. Sua **chave pública de serviço** -2. Sua **chave pública de gerenciador de recompensas** (do Passo 2.3) -3. Seu **nome de usuário do GitHub** (para acesso ao repositório) - -Envie as três juntas. A DZF registra a chave de serviço e a chave de gerenciador de recompensas em transações onchain separadas, então enviá-las ao mesmo tempo economiza uma ida e volta. +Eles criam sua **conta de contribuidor** on-chain e confirmam quando estiver concluído. !!! danger "Apenas chaves públicas" - Nunca envie uma chave privada ou um arquivo de par de chaves para ninguém, incluindo a DZF. A DZF só precisa das suas chaves públicas. - -Eles irão: + Nunca envie uma chave privada ou um arquivo de par de chaves para ninguém, incluindo a DZF. Apenas a chave pública é necessária. -- Criar sua **conta de contribuidor** onchain -- Registrar sua **chave de gerenciador de recompensas** associada à sua chave de serviço -- Conceder acesso ao **repositório privado de contribuidores** +### Etapa 2.5: Verificar Sua Conta -### Passo 2.5: Verificar Sua Conta - -Uma vez confirmado, verifique se sua conta de contribuidor existe: +Após a confirmação, verifique se sua conta de contribuidor existe: ```bash doublezero contributor list ``` -Você deve ver seu código de contribuidor na lista. - -Verifique se sua chave de gerenciador de recompensas também foi registrada: - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` - -A coluna `manager` deve mostrar sua chave pública de gerenciador de recompensas. Se estiver vazia, peça à DZF para completar essa etapa. - -### Passo 2.6: Acessar o Repositório de Contribuidores - -O repositório [malbeclabs/contributors](https://github.com/malbeclabs/contributors) contém: - -- Configurações base de dispositivos -- Perfis TCAM -- Configurações de ACL -- Instruções adicionais de configuração +Você deverá ver seu código de contribuidor na lista. -Siga as instruções lá para configuração específica do dispositivo. +### Etapa 2.6: Configurar o Gerenciamento de Recompensas -### Passo 2.7: Definir Seus Destinatários de Recompensa +O gerenciamento de recompensas decide quais carteiras recebem os [2Z](glossary.md#2z-token) que sua contribuição gera, e em quais proporções. -Agora defina quais carteiras recebem suas recompensas, e em quais proporções. Faça isso antes que seu dispositivo comece a transportar tráfego. As recompensas se acumulam a partir do momento em que seus links estão ativos, mas o protocolo não pode pagá-las até que você tenha indicado carteiras destinatárias. +Siga as instruções em [Gerenciamento de Recompensas](https://github.com/malbeclabs/contributors#rewards-management) no repositório de contribuidores, ao qual você agora tem acesso a partir da Etapa 2.1. -Acesse [doublezero.xyz/rewards](https://doublezero.xyz/rewards) com sua carteira de gerenciador de recompensas, selecione sua chave de serviço e insira cada carteira destinatária e sua porcentagem. As porcentagens devem somar 100. - -!!! warning "Cada destinatário precisa de uma conta de token 2Z" - O protocolo envia 2Z com uma transferência de token simples e não cria a conta de token para você. Uma carteira destinatária sem conta de token 2Z faz com que o pagamento daquela época falhe. - -Veja [Gerenciamento de Recompensas](contribute-rewards.md) para o passo a passo completo, incluindo a alternativa via CLI, como verificar a conta de token e como verificar o resultado. +!!! note "Isso não bloqueia o restante da sua configuração" + Você pode provisionar seu dispositivo, estabelecer links e começar a transportar tráfego sem isso configurado, então trate as fases abaixo como independentes disso. --- @@ -361,13 +327,13 @@ flowchart LR | Tipo | O Que Faz | Quando Usar | |------|-----------|-------------| -| **Edge** | Aceita apenas conexões de usuários | Localização única, apenas voltado ao usuário | +| **Edge** | Aceita apenas conexões de usuários | Localização única, voltado apenas ao usuário | | **Transit** | Move tráfego entre dispositivos | Conectividade de backbone, sem usuários | | **Hybrid** | Conexões de usuários E backbone | Mais comum - faz tudo | -### Passo 3.1: Encontrar Sua Localização e Exchange +### Etapa 3.1: Encontre Sua Localização e Exchange -Antes de criar seu dispositivo, consulte os códigos da localização do seu data center e do exchange mais próximo: +Antes de criar seu dispositivo, procure os códigos da localização do seu data center e do exchange mais próximo: ```bash # Listar localizações disponíveis (data centers) @@ -377,7 +343,7 @@ doublezero location list doublezero exchange list ``` -### Passo 3.2: Criar Seu Dispositivo Onchain +### Etapa 3.2: Criar Seu Dispositivo On-chain Registre seu dispositivo na blockchain: @@ -386,8 +352,8 @@ doublezero device create \ --code \ --contributor \ --device-type hybrid \ - --location \ - --exchange \ + --location \ + --exchange \ --public-ip \ --dz-prefixes ``` @@ -417,19 +383,19 @@ Verifique se seu dispositivo foi criado: doublezero device list | grep nyc-dz001 ``` -**Explicação dos parâmetros:** +**Parâmetros explicados:** | Parâmetro | O Que Significa | |-----------|-----------------| -| `--code` | Um nome único para seu dispositivo (ex: `nyc-dz001`) | +| `--code` | Um nome único para seu dispositivo (ex.: `nyc-dz001`) | | `--contributor` | Seu código de contribuidor (fornecido pela DZF) | | `--device-type` | `hybrid`, `transit` ou `edge` | | `--location` | Código do data center obtido de `location list` | | `--exchange` | Código do exchange mais próximo obtido de `exchange list` | -| `--public-ip` | O IP público onde os usuários se conectam ao seu dispositivo pela internet | +| `--public-ip` | O IP público onde os usuários se conectam ao seu dispositivo via internet | | `--dz-prefixes` | Seu bloco de IPs alocado para usuários | -### Passo 3.3: Criar Interfaces Loopback Obrigatórias +### Etapa 3.3: Criar Interfaces Loopback Obrigatórias Todo dispositivo precisa de duas interfaces loopback para roteamento interno: @@ -447,9 +413,9 @@ doublezero device interface create Loopback256 --loopbac Signature: 3mNx9K...truncated...8wRt5 ``` -### Passo 3.4: Criar Interfaces Físicas +### Etapa 3.4: Criar Interfaces Físicas -Registre as interfaces físicas que serão usadas para links WAN ou DZX. Estas interfaces devem existir on-chain antes que você possa criar um link que as referencie. Neste passo você apenas registra a interface e sua largura de banda — o link é criado em um passo posterior. +Registre as interfaces físicas que serão usadas para links WAN ou DZX. Essas interfaces devem existir on-chain antes que você possa criar um link que as referencie. Nesta etapa você apenas registra a interface e sua largura de banda; o link é criado em uma etapa posterior. ```bash doublezero device interface create \ @@ -469,15 +435,15 @@ doublezero device interface create nyc-dz001 Ethernet1/1 \ Signature: 7pQw2R...truncated...4xKm9 ``` -Repita isso para cada interface que será usada como endpoint de link WAN ou DZX. Interfaces CYOA e DIA são registradas separadamente no próximo passo. +Repita isso para cada interface que será usada como endpoint de link WAN ou DZX. As interfaces CYOA e DIA são registradas separadamente na próxima etapa. -### Passo 3.5: Criar Interface CYOA (para dispositivos Edge/Hybrid) +### Etapa 3.5: Criar Interface CYOA (para dispositivos Edge/Hybrid) -DZDs hybrid e edge precisam de **dois endereços IP públicos** nos quais os usuários terminam seus túneis GRE. Os usuários podem se conectar via unicast, multicast ou ambos, e qual IP serve a qual propósito rotaciona por usuário. +DZDs hybrid e edge precisam de **dois endereços IP públicos** nos quais os usuários terminam seus túneis GRE. Os usuários podem se conectar via unicast, multicast ou ambos, e qual IP serve a qual propósito é alternado por usuário. -Ambos os IPs devem ser registrados com `--user-tunnel-endpoint true`, em uma interface física ou em um loopback. Isso inclui o IP que você forneceu no momento da criação do dispositivo — esse IP ainda precisa ser explicitamente registrado aqui. +Ambos os IPs devem ser registrados com `--user-tunnel-endpoint true`, seja em uma interface física ou em um loopback. Isso inclui o IP que você forneceu no momento da criação do dispositivo — esse IP ainda precisa ser explicitamente registrado aqui. -Se você tem restrição de IPs, pode usar o primeiro `/32` do seu prefixo DZ como um dos dois IPs. +Se você estiver com restrição de IPs, pode usar o primeiro `/32` do seu prefixo DZ como um dos dois IPs. #### CYOA e DIA @@ -486,19 +452,19 @@ Se você tem restrição de IPs, pode usar o primeiro `/32` do seu prefixo DZ co | DIA | `--interface-dia dia` | Marca a porta como acesso direto à internet | | CYOA | `--interface-cyoa ` | Declara como os usuários conectam túneis GRE ao seu dispositivo | -A flag CYOA é sempre definida em uma **interface física** (porta Ethernet ou port channel). Nunca em um loopback. +A flag CYOA é sempre definida em uma **interface física** (porta Ethernet ou canal de porta). Nunca em um loopback. | Subtipo CYOA | Quando usar | |--------------|-------------| | `gre-over-dia` | Usuários se conectam pela internet pública. Mais comum. | | `gre-over-private-peering` | Usuários se conectam via cross-connect direto ou circuito privado | | `gre-over-public-peering` | Usuários fazem peering com você em um Internet Exchange (IX) | -| `gre-over-fabric` | Usuários estão co-localizados e se conectam via fabric local | -| `gre-over-cable` | Conexão por cabo direto a um único usuário dedicado | +| `gre-over-fabric` | Usuários estão co-localizados e se conectam por um fabric local | +| `gre-over-cable` | Conexão direta por cabo com um único usuário dedicado | #### Cenário A: Interface física única -Um único uplink físico para o ISP. Ethernet1/1 é a interface CYOA e DIA e possui um dos dois IPs públicos. Loopback100 possui o segundo IP público. +Um único uplink físico para o ISP. Ethernet1/1 é a interface CYOA e DIA e carrega um dos dois IPs públicos. Loopback100 carrega o segundo IP público. ```mermaid flowchart LR @@ -523,7 +489,7 @@ flowchart LR | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade da porta | taxa garantida | `bgp` ou `static` | `true` | +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade da porta | taxa comprometida | `bgp` ou `static` | `true` | | Loopback100 | — | — | seu /32 público | `0bps` | — | — | `true` | Exemplo de comandos a executar baseados no Cenário A: @@ -543,9 +509,9 @@ doublezero device interface create mydzd-nyc01 Loopback100 \ --user-tunnel-endpoint true ``` -#### Cenário B: Port channel (LAG) +#### Cenário B: Canal de porta (LAG) -O DZD se conecta ao dispositivo upstream via um port channel com um IP. O port channel possui um IP público e é o endpoint CYOA. Loopback100 possui o segundo IP público. +O DZD se conecta ao dispositivo upstream via um canal de porta com IP. O canal de porta carrega um IP público e é o endpoint CYOA. Loopback100 carrega o segundo IP público. ```mermaid flowchart LR @@ -573,7 +539,7 @@ flowchart LR | Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| -| Port-Channel1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade combinada do LAG | taxa garantida | `bgp` ou `static` | `true` | +| Port-Channel1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade combinada do LAG | taxa comprometida | `bgp` ou `static` | `true` | | Loopback100 | — | — | seu /32 público | `0bps` | — | — | `true` | Exemplo de comandos a executar baseados no Cenário B: @@ -603,4 +569,38 @@ flowchart LR USERS(["Usuários Finais"]) RA["Roteador A - 203.0.113.2 \ No newline at end of file + 203.0.113.2/30"] + RB["Roteador B + 203.0.113.6/30"] + + subgraph DZD["DZD"] + E1["Eth1/1 + 203.0.113.1/30 + CYOA · DIA"] + E2["Eth2/1 + 203.0.113.5/30 + CYOA · DIA"] + LO0["Loopback100 + 198.51.100.1/32\n endpoint de túnel do usuário"] + LO1["Loopback101 + 198.51.100.2/32\n endpoint de túnel do usuário"] + E1 --> LO0 + E2 --> LO1 + end + + RA -- "10GbE" --- E1 + RB -- "10GbE" --- E2 + USERS -. "Túneis GRE" .-> LO0 + USERS -. "Túneis GRE" .-> LO1 +``` + +| Interface | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | +|-----------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| +| Ethernet1/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade da porta | taxa comprometida | `bgp` ou `static` | — | +| Ethernet2/1 | `gre-over-dia` | `dia` | IP/sub-rede atribuído pelo contribuidor | velocidade da porta | taxa comprometida | `bgp` ou `static` | — | +| Loopback100 | — | — | seu /32 público | `0bps` | — | — | `true` | +| Loopback101 | — | — | seu /32 público | `0bps` | — | — | `true` | + +Exemplo de comandos a executar baseados no Cenário C: +```bash +doublezero device interface create mydz \ No newline at end of file diff --git a/docs/contribute-provisioning.zh.md b/docs/contribute-provisioning.zh.md index 3ced045..d912e43 100644 --- a/docs/contribute-provisioning.zh.md +++ b/docs/contribute-provisioning.zh.md @@ -1,44 +1,44 @@ --- -description: 逐步指南：配置 DoubleZero 设备 (DZD) 并在链上注册其接口和角色。 +description: 配置 DoubleZero 设备 (DZD) 并在链上注册其接口和角色的分步指南。 --- # 设备配置指南 -本指南将带您从头到尾完成 DoubleZero 设备 (DZD) 的配置。每个阶段对应[上线清单](contribute-overview.md#onboarding-checklist)中的相应步骤。 +本指南将引导您从头到尾完成 DoubleZero 设备 (DZD) 的配置。每个阶段对应[上线清单](contribute-overview.md#onboarding-checklist)中的步骤。 --- -## 整体架构概览 +## 整体架构 -本指南将引导您在链上注册基础设施，以便 DoubleZero 网络能够通过您的设备路由流量。设备注册得越完整，它对网络的价值就越大。完整的链上设备表示能够实现更好的故障排查、容量规划，并让控制器做出更明智的决策。随着时间推移，目标是让控制器承担更多的配置责任。 +本指南将引导您在链上注册基础设施，以便 DoubleZero 网络能够通过其路由流量。您的设备注册得越完整，对网络的价值就越大。设备在链上的完整表示有助于更好地进行故障排除、容量规划，并允许控制器做出明智的决策。随着时间推移，目标是让控制器承担更多的配置职责。 -### 核心概念 +### 关键概念 **接口** -DZD 上的接口有多种形式：以太网端口、端口通道（由多个以太网端口组成的 LAG）和环回接口。每个在网络中发挥作用的接口都需要在链上注册，并设置适当的标志，以便协议了解其功能。 +DZD 上的接口有多种形式：以太网端口、端口通道（由多个以太网端口组成的 LAG）和环回接口。每个在网络中发挥作用的接口都需要在链上注册并附上适当的标志，以便协议了解其功能。 以太网端口和端口通道可以承担以下角色： | 标志 | 含义 | |------|------| -| `--interface-dia dia` | 将接口标记为直接互联网接入上行链路 | -| `--interface-cyoa ` | 声明用户如何通过该接口建立 GRE 隧道（例如通过公共互联网、通过私有对等链路） | -| `--user-tunnel-endpoint true` | 该接口承载用户终止 GRE 隧道所用的公共 IP | +| `--interface-dia dia` | 将该接口标记为直接互联网接入上行链路 | +| `--interface-cyoa ` | 声明用户通过此接口建立 GRE 隧道的方式（例如通过公共互联网、通过私有对等链路） | +| `--user-tunnel-endpoint true` | 此接口携带用户终止 GRE 隧道的公共 IP | -用于 WAN 或 DZX 链路的接口不需要特定标志，只需注册其带宽，然后在创建链路时引用即可。 +用于 WAN 或 DZX 链路的接口不需要特定标志，它们仅注册带宽，然后在创建链路时被引用。 环回接口有多种用途： | 环回接口 | 含义 | |----------|------| -| **Loopback100 / 101** | 承载用户终止 GRE 隧道所用的公共 IP。使用 `--user-tunnel-endpoint true` 注册。 | -| **Loopback255** (`vpnv4`) | 注册后控制器可以分配用于 BGP 路由器 ID、VPN-IPv4 对等（单播）、IS-IS 身份和段路由的 IP | -| **Loopback256** (`ipv4`) | 注册后控制器可以分配用于 IPv4 BGP 对等（组播）和 MSDP 会话的 IP | +| **Loopback100 / 101** | 携带用户终止 GRE 隧道的公共 IP。使用 `--user-tunnel-endpoint true` 注册。 | +| **Loopback255** (`vpnv4`) | 注册后控制器可分配 IP，用于 BGP 路由器 ID、VPN-IPv4 对等（单播）、IS-IS 标识和段路由 | +| **Loopback256** (`ipv4`) | 注册后控制器可分配 IP，用于 IPv4 BGP 对等（组播）和 MSDP 会话 | **链路** -链路与接口分开注册，且接口必须先在链上存在，链路才能引用它们。创建 WAN 或 DZX 链路时，您需要指定一个已注册的接口作为链路的物理端点。并非所有接口都与链路关联：DIA、CYOA 和环回接口不连接到链路。 +链路与接口分开注册，且接口必须先在链上存在，链路才能引用它们。当您创建 WAN 或 DZX 链路时，需要指定一个已注册的接口作为链路的物理端点。并非所有接口都关联到链路：DIA、CYOA 和环回接口不连接到链路。 | 术语 | 含义 | |------|------| @@ -61,11 +61,11 @@ flowchart TB DZX_INTF["DZX 链路接口"] LO100["Loopback100/101
(用户隧道端点)"] end - DZD2[您的另一个 DZD] + DZD2[您的其他 DZD] end subgraph Other Contributor - OtherDZD[对方的 DZD] + OtherDZD[其他贡献者的 DZD] end USERS["用户"] @@ -74,29 +74,29 @@ flowchart TB WAN_INTF ---|WAN 链路| DZD2 DZX_INTF ---|DZX 链路| OtherDZD USERS -.|GRE 隧道|.-> CYOA - CYOA ---|路由至| LO100 + CYOA ---|路由到| LO100 ``` --- ## 阶段 1：前提条件 -在配置设备之前，您需要先完成物理硬件安装并分配一些 IP 地址。 +在配置设备之前，您需要完成物理硬件的安装并分配一些 IP 地址。 -### 准备事项 +### 所需条件 | 要求 | 原因 | |------|------| | **DZD 硬件** | Arista 7280CR3A 交换机（参见[硬件规格](contribute.md#hardware-requirements)） | -| **机柜空间** | 每个 DZD 需要 1U，确保良好的气流。参见[机柜与电源](contribute.md#rack-power-requirements) | -| **电源** | 两路独立供电，每路都能独立承担全部负载。参见[机柜与电源](contribute.md#rack-power-requirements) | -| **管理访问** | 通过 SSH/控制台访问来配置交换机 | -| **互联网连接** | 用于发布指标数据和从控制器获取配置 | -| **公共 IPv4 地址块** | DZ 前缀池至少需要 /29（见下文） | +| **机架空间** | 每个 DZD 预留 2U（目前使用 1U），需确保良好的气流。参见[机架与电源](contribute.md#rack-power-requirements) | +| **电源** | 两路独立供电，每路均能独立承担全部负载。参见[机架与电源](contribute.md#rack-power-requirements) | +| **管理访问** | 通过 SSH/控制台访问以配置交换机 | +| **互联网连接** | 用于发布指标和从控制器获取配置 | +| **公共 IPv4 地址块** | DZ 前缀池最少需要 /29（见下文） | ### 安装 DoubleZero CLI -DoubleZero CLI (`doublezero`) 在整个配置过程中用于注册设备、创建链路和管理您的贡献。它应安装在**管理服务器或虚拟机**上——而不是 DZD 交换机上。交换机只运行配置代理和遥测代理（在[阶段 4](#phase-4-link-establishment-agent-installation) 中安装）。 +DoubleZero CLI (`doublezero`) 在整个配置过程中用于注册设备、创建链路和管理您的贡献。它应安装在**管理服务器或虚拟机**上 — 而非 DZD 交换机本身。交换机仅运行配置代理和遥测代理（在[阶段 4](#phase-4-link-establishment-agent-installation) 中安装）。 **Ubuntu / Debian：** ```bash @@ -110,14 +110,14 @@ curl -1sLf https://dl.cloudsmith.io/public/malbeclabs/doublezero/setup.rpm.sh | sudo yum install doublezero ``` -验证守护进程正在运行： +验证守护进程是否正在运行： ```bash sudo systemctl status doublezerod ``` ### 了解您的 DZ 前缀 -DZ 前缀是 DoubleZero 协议用于 IP 分配管理的一组公共 IP 地址。 +您的 DZ 前缀是一组由 DoubleZero 协议管理的公共 IP 地址块，用于 IP 分配。 ```mermaid flowchart LR @@ -152,10 +152,10 @@ flowchart LR **要求：** - - 必须是**全球可路由（公共）**的 IPv4 地址 - - 私有 IP 范围（10.x、172.16-31.x、192.168.x）会被智能合约拒绝 - - **最小大小：/29**（8 个地址），推荐更大的前缀（例如 /28、/27） - - 整个地址块必须可用——不要预先分配任何地址 + - 必须是**全局可路由（公共）**的 IPv4 地址 + - 私有 IP 范围（10.x、172.16-31.x、192.168.x）将被智能合约拒绝 + - **最小大小：/29**（8 个地址），建议使用更大的前缀（如 /28、/27） + - 整个地址块必须可用 — 不要预先分配任何地址 如果您需要为自己的设备分配地址（DIA 接口 IP、管理等），请使用**单独的地址池**。 @@ -163,14 +163,14 @@ flowchart LR ## 阶段 2：账户设置 -在此阶段，您将创建用于在网络上标识您和您设备的加密密钥，并指定奖励支付地址。 +在此阶段，您将创建用于在网络上标识您和您设备的加密密钥，并设置奖励管理。 -此阶段将生成三个密钥：服务密钥、指标发布密钥和奖励管理密钥。请在[步骤 2.4](#step-24-submit-keys-to-dzf) 中将这三个密钥的公钥一并提交给 DZF。[奖励管理](contribute-rewards.md)详细介绍了奖励相关内容。 +这些步骤按特定顺序执行是有原因的：首先获取仓库访问权限，因为仓库包含后续步骤的说明，然后是密钥，再是奖励。某些步骤需要 DZF 先行操作才能继续，以下每个步骤都会说明这一点。 ### CLI 运行位置 -!!! warning "请勿在交换机上安装 CLI" - DoubleZero CLI (`doublezero`) 应安装在**管理服务器或虚拟机**上，而不是 Arista 交换机上。 +!!! warning "不要在交换机上安装 CLI" + DoubleZero CLI (`doublezero`) 应安装在**管理服务器或虚拟机**上，而非 Arista 交换机上。 ```mermaid flowchart LR @@ -193,24 +193,24 @@ flowchart LR |--------------------|----------------| | `doublezero` CLI | 配置代理 | | 您的服务密钥对 | 遥测代理 | - | 您的指标发布密钥对 | 指标发布密钥对（副本） | + | 您的指标发布者密钥对 | 指标发布者密钥对（副本） | ### 什么是密钥？ 可以将密钥理解为安全登录凭据： -- **服务密钥**：您的贡献者身份——用于运行 CLI 命令 -- **指标发布密钥**：您设备提交遥测数据的身份标识 -- **奖励管理密钥**：控制哪些钱包接收您的奖励——参见[奖励管理](contribute-rewards.md) +- **服务密钥**：您的贡献者身份 - 用于运行 CLI 命令 +- **指标发布者密钥**：您设备提交遥测数据的身份标识 +- **奖励管理者密钥**：控制哪些钱包接收您的奖励 - 参见贡献者仓库中的[奖励管理](https://github.com/malbeclabs/contributors#rewards-management) -三者都是加密密钥对（一个用于共享的公钥和一个需要保密的私钥）。 +这三个都是加密密钥对（一个公开共享的公钥和一个保密的私钥）。 ```mermaid flowchart LR subgraph "您的密钥" SK[服务密钥
~/.config/solana/id.json] - MK[指标发布密钥
~/.config/doublezero/metrics-publisher.json] - RK[奖励管理密钥
离线保管] + MK[指标发布者密钥
~/.config/doublezero/metrics-publisher.json] + RK[奖励管理者密钥
离线保存] end SK -->|用于| CLI[CLI 命令
doublezero device create
doublezero link create] @@ -218,10 +218,16 @@ flowchart LR RK -->|用于| REW[奖励门户
设置接收钱包] ``` -!!! note "单独保管奖励管理密钥" - 服务密钥和指标发布密钥存放在您的管理服务器和交换机上。奖励管理密钥控制您的资金去向，因此请将其存放在这些机器之外。只有在更改接收钱包时才需要使用它。 +!!! note "将奖励管理者密钥单独保存" + 服务密钥和指标发布者密钥存储在您的管理服务器和交换机上。奖励管理者密钥控制您的资金流向，因此请将其保存在这些机器之外。仅在更改接收钱包时才需要使用它。 -### 步骤 2.1：生成您的服务密钥 +### 步骤 2.1：申请贡献者仓库访问权限 + +联系 DoubleZero Foundation 或 Malbec Labs，并提供您的 **GitHub 用户名**。 + +他们会授予您访问私有 [malbeclabs/contributors](https://github.com/malbeclabs/contributors) 仓库的权限。请首先完成此步骤：该仓库包含基础设备配置、TCAM 和 ACL 配置文件，以及您在后续步骤中需要的奖励管理说明。 + +### 步骤 2.2：生成您的服务密钥 这是您与 DoubleZero 交互的主要身份标识。 @@ -229,42 +235,24 @@ flowchart LR doublezero keygen ``` -这会在默认位置创建一个密钥对。输出会显示您的**公钥**——这是您需要与 DZF 共享的内容。 +这将在默认位置创建一个密钥对。输出会显示您的**公钥** - 这是您将与 DZF 共享的内容。 -### 步骤 2.2：生成您的指标发布密钥 +### 步骤 2.3：生成您的指标发布者密钥 -此密钥由遥测代理用于签名指标提交。 +此密钥由遥测代理用于签署指标提交。 ```bash doublezero keygen -o ~/.config/doublezero/metrics-publisher.json ``` -### 步骤 2.3：创建您的奖励管理钱包 - -这是第三个密钥。它控制哪些钱包接收您的奖励，但它本身不持有奖励。 - -创建一个您能控制和签名的 Solana 钱包，然后充入约 0.01 SOL 以支付交易手续费。硬件钱包是一个不错的选择。不要重复使用您的服务密钥。 - -目前您只需要准备好钱包。在 DZF 注册此密钥后，您将在[步骤 2.7](#step-27-set-your-reward-recipients) 中设置实际接收奖励的钱包。 - -### 步骤 2.4：向 DZF 提交密钥 +### 步骤 2.4：向 DZF 提交您的服务密钥 -联系 DoubleZero Foundation 或 Malbec Labs，提供以下信息： +将您的**服务密钥公钥**发送给 DZF。 -1. 您的**服务密钥公钥** -2. 您的**奖励管理公钥**（来自步骤 2.3） -3. 您的 **GitHub 用户名**（用于获取仓库访问权限） +他们会在链上创建您的**贡献者账户**，并在完成后确认。 -请一并发送所有三项。DZF 会通过单独的链上交易注册服务密钥和奖励管理密钥，因此同时发送可以减少一次往返。 - -!!! danger "仅提供公钥" - 切勿向任何人发送私钥或密钥对文件，包括 DZF。DZF 只需要您的公钥。 - -他们将： - -- 在链上创建您的**贡献者账户** -- 将您的**奖励管理密钥**与服务密钥关联注册 -- 授予您访问私有**贡献者仓库**的权限 +!!! danger "仅限公钥" + 切勿向任何人（包括 DZF）发送私钥或密钥对文件。只需要公钥即可。 ### 步骤 2.5：验证您的账户 @@ -276,36 +264,14 @@ doublezero contributor list 您应该在列表中看到您的贡献者代码。 -同时检查您的奖励管理密钥是否已注册： - -```bash -doublezero-solana revenue-distribution fetch contributor-rewards \ - --service-key -u mainnet-beta -``` +### 步骤 2.6：设置奖励管理 -`manager` 列应显示您的奖励管理公钥。如果为空，请要求 DZF 完成该步骤。 +奖励管理决定哪些钱包接收您的贡献所赚取的 [2Z](glossary.md#2z-token)，以及各自的比例。 -### 步骤 2.6：访问贡献者仓库 +请按照贡献者仓库中的[奖励管理](https://github.com/malbeclabs/contributors#rewards-management)说明操作，您在步骤 2.1 中已获得了该仓库的访问权限。 -[malbeclabs/contributors](https://github.com/malbeclabs/contributors) 仓库包含： - -- 基础设备配置 -- TCAM 配置文件 -- ACL 配置 -- 额外的设置说明 - -请按照其中的说明进行设备特定的配置。 - -### 步骤 2.7：设置您的奖励接收方 - -现在指定哪些钱包接收您的奖励，以及各自的比例。请在您的设备开始承载流量之前完成此操作。奖励从您的链路上线那一刻就开始累积，但在您指定接收钱包之前，协议无法进行支付。 - -使用您的奖励管理钱包登录 [doublezero.xyz/rewards](https://doublezero.xyz/rewards)，选择您的服务密钥，然后输入每个接收钱包及其百分比。百分比之和必须为 100。 - -!!! warning "每个接收方都需要 2Z 代币账户" - 协议通过普通代币转账发送 2Z，不会为您创建代币账户。如果接收钱包没有 2Z 代币账户，会导致该纪元的支付失败。 - -参见[奖励管理](contribute-rewards.md)获取完整操作指南，包括 CLI 替代方式、如何检查代币账户以及如何验证结果。 +!!! note "这不会阻碍您的其余设置" + 您可以在未完成此步骤的情况下配置设备、建立链路并开始承载流量，因此请将以下阶段视为独立于此步骤。 --- @@ -315,7 +281,7 @@ doublezero-solana revenue-distribution fetch contributor-rewards \ ### 了解设备类型 -**边缘设备（Edge）** — 仅接受用户连接 +**边缘（Edge）** — 仅接受用户连接 ```mermaid flowchart LR @@ -330,7 +296,7 @@ flowchart LR E_DZX <-->|DZX 链路| ED["DZD（不同贡献者）"] ``` -**中转设备（Transit）** — 在设备间转发流量，无用户连接 +**中转（Transit）** — 在设备之间传输流量，无用户连接 ```mermaid flowchart LR @@ -342,7 +308,7 @@ flowchart LR T_DZX <-->|DZX 链路| TD["DZD（不同贡献者）"] ``` -**混合设备（Hybrid）** — 用户连接和骨干传输兼备，最常见 +**混合（Hybrid）** — 用户连接和骨干网，最常见 ```mermaid flowchart LR @@ -359,21 +325,21 @@ flowchart LR H_DZX <-->|DZX 链路| HD["DZD（不同贡献者）"] ``` -| 类型 | 功能 | 适用场景 | +| 类型 | 功能 | 使用场景 | |------|------|----------| -| **边缘（Edge）** | 仅接受用户连接 | 单一位置，仅面向用户 | -| **中转（Transit）** | 在设备间转发流量 | 骨干连接，无用户 | -| **混合（Hybrid）** | 兼具用户连接和骨干功能 | 最常见——全能型 | +| **边缘** | 仅接受用户连接 | 单一位置，仅面向用户 | +| **中转** | 在设备之间传输流量 | 骨干网连接，无用户 | +| **混合** | 用户连接和骨干网兼备 | 最常见 - 功能全面 | -### 步骤 3.1：查找您的位置和交换点 +### 步骤 3.1：查找您的位置和交换节点 -在创建设备之前，查找您的数据中心位置和最近交换点的代码： +在创建设备之前，查找您数据中心位置和最近交换节点的代码： ```bash # 列出可用位置（数据中心） doublezero location list -# 列出可用交换点（互联点） +# 列出可用交换节点（互联点） doublezero exchange list ``` @@ -421,17 +387,17 @@ doublezero device list | grep nyc-dz001 | 参数 | 含义 | |------|------| -| `--code` | 您设备的唯一名称（例如 `nyc-dz001`） | +| `--code` | 设备的唯一名称（例如 `nyc-dz001`） | | `--contributor` | 您的贡献者代码（由 DZF 提供） | | `--device-type` | `hybrid`、`transit` 或 `edge` | | `--location` | 从 `location list` 获取的数据中心代码 | -| `--exchange` | 从 `exchange list` 获取的最近交换点代码 | +| `--exchange` | 从 `exchange list` 获取的最近交换节点代码 | | `--public-ip` | 用户通过互联网连接到您设备的公共 IP | | `--dz-prefixes` | 为用户分配的 IP 地址块 | ### 步骤 3.3：创建必需的环回接口 -每个设备都需要两个用于内部路由的环回接口： +每个设备需要两个用于内部路由的环回接口： ```bash # VPNv4 环回 @@ -473,32 +439,32 @@ Signature: 7pQw2R...truncated...4xKm9 ### 步骤 3.5：创建 CYOA 接口（适用于边缘/混合设备） -混合和边缘 DZD 需要**两个公共 IP 地址**供用户终止其 GRE 隧道。用户可以通过单播、组播或两者同时连接，哪个 IP 服务于哪个用途会按用户轮换。 +混合和边缘 DZD 需要**两个公共 IP 地址**，供用户终止其 GRE 隧道。用户可能通过单播、组播或两者同时连接，哪个 IP 用于哪个用途会按用户轮换。 -两个 IP 都必须以 `--user-tunnel-endpoint true` 注册，可以在物理接口或环回接口上。这包括您在设备创建时提供的 IP——该 IP 仍需在此处显式注册。 +两个 IP 都必须使用 `--user-tunnel-endpoint true` 注册，可以在物理接口或环回接口上。这包括您在创建设备时提供的 IP，该 IP 仍需在此处显式注册。 -如果您的 IP 资源紧张，可以使用 DZ 前缀的第一个 `/32` 作为两个 IP 之一。 +如果您的 IP 资源有限，可以使用 DZ 前缀的第一个 `/32` 作为两个 IP 之一。 #### CYOA 和 DIA | 类型 | 标志 | 用途 | |------|------|------| | DIA | `--interface-dia dia` | 将端口标记为直接互联网接入 | -| CYOA | `--interface-cyoa ` | 声明用户如何将 GRE 隧道连接到您的设备 | +| CYOA | `--interface-cyoa ` | 声明用户如何通过 GRE 隧道连接到您的设备 | -CYOA 标志始终设置在**物理接口**（以太网端口或端口通道）上，不能设置在环回接口上。 +CYOA 标志始终设置在**物理接口**（以太网端口或端口通道）上。绝不在环回接口上设置。 | CYOA 子类型 | 使用场景 | |-------------|----------| | `gre-over-dia` | 用户通过公共互联网连接。最常见。 | -| `gre-over-private-peering` | 用户通过直连交叉连接或专用线路连接 | -| `gre-over-public-peering` | 用户在互联网交换中心 (IX) 与您对等 | -| `gre-over-fabric` | 用户同地部署，通过本地交换网络连接 | -| `gre-over-cable` | 直接线缆连接到单个专用用户 | +| `gre-over-private-peering` | 用户通过直连交叉连接或私有线路连接 | +| `gre-over-public-peering` | 用户在互联网交换点 (IX) 与您对等 | +| `gre-over-fabric` | 用户在同一机房，通过本地交换网络连接 | +| `gre-over-cable` | 直接电缆连接到单个专用用户 | #### 场景 A：单物理接口 -一条连接到 ISP 的物理上行链路。Ethernet1/1 是 CYOA 和 DIA 接口，承载两个公共 IP 之一。Loopback100 承载第二个公共 IP。 +一条到 ISP 的物理上行链路。Ethernet1/1 是 CYOA 和 DIA 接口，携带两个公共 IP 中的一个。Loopback100 携带第二个公共 IP。 ```mermaid flowchart LR @@ -545,13 +511,13 @@ doublezero device interface create mydzd-nyc01 Loopback100 \ #### 场景 B：端口通道（LAG） -DZD 通过带有 IP 的端口通道连接到上游设备。端口通道承载一个公共 IP，作为 CYOA 端点。Loopback100 承载第二个公共 IP。 +DZD 通过带有 IP 的端口通道连接到上游设备。端口通道携带一个公共 IP，是 CYOA 端点。Loopback100 携带第二个公共 IP。 ```mermaid flowchart LR USERS(["终端用户"]) - subgraph SW["上游路由器/交换机"] + subgraph SW["上游路由器 / 交换机"] SWPC(["bond0 203.0.113.2/30"]) end @@ -574,4 +540,52 @@ flowchart LR | 接口 | `--interface-cyoa` | `--interface-dia` | `--ip-net` | `--bandwidth` | `--cir` | `--routing-mode` | `--user-tunnel-endpoint` | |------|-------------------|------------------|------------|---------------|---------|-----------------|--------------------------| | Port-Channel1 | `gre-over-dia` | `dia` | 贡献者分配的 IP/子网 | LAG 组合速率 | 承诺速率 | `bgp` 或 `static` | `true` | -| Loopback100 | — | — \ No newline at end of file +| Loopback100 | — | — | 您的公共 /32 | `0bps` | — | — | `true` | + +基于场景 B 执行的命令示例： +```bash +doublezero device interface create mydzd-fra01 Port-Channel1 \ + --interface-cyoa gre-over-dia \ + --interface-dia dia \ + --ip-net 203.0.113.1/30 \ + --bandwidth 20Gbps \ + --cir 2Gbps \ + --routing-mode bgp \ + --user-tunnel-endpoint true + +doublezero device interface create mydzd-fra01 Loopback100 \ + --ip-net 198.51.100.1/32 \ + --bandwidth 0bps \ + --user-tunnel-endpoint true +``` + + +#### 场景 C：双物理上行链路连接到不同路由器 + +每个物理接口连接到不同的上游路由器。两个公共 IP 分别位于 Loopback100 和 Loopback101 上，均注册为用户隧道端点。 + +```mermaid +flowchart LR + USERS(["终端用户"]) + + RA["路由器 A + 203.0.113.2/30"] + RB["路由器 B + 203.0.113.6/30"] + + subgraph DZD["DZD"] + E1["Eth1/1 + 203.0.113.1/30 + CYOA · DIA"] + E2["Eth2/1 + 203.0.113.5/30 + CYOA · DIA"] + LO0["Loopback100 + 198.51.100.1/32\n 用户隧道端点"] + LO1["Loopback101 + 198.51.100.2/32\n 用户隧道端点"] + E1 --> LO0 + E2 --> LO1 + end + + RA -- "10Gb \ No newline at end of file diff --git a/docs/contribute.es.md b/docs/contribute.es.md index fc2804a..adfed39 100644 --- a/docs/contribute.es.md +++ b/docs/contribute.es.md @@ -6,9 +6,9 @@ description: Requisitos de hardware, ancho de banda y conectividad, así como ar ## Resumen -Cualquier persona que desee monetizar sus cables de fibra óptica y hardware de red subutilizados puede contribuir a la red DoubleZero. Los contribuidores de red deben proporcionar ancho de banda dedicado entre dos puntos, operar dispositivos compatibles con DoubleZero (DZDs) en cada extremo, y una conexión a internet pública en cada extremo. Los contribuidores de red también deben ejecutar el software de DoubleZero en cada DZD para proporcionar servicios como multicast, búsqueda de usuarios y filtrado en el borde. +Cualquier persona que desee monetizar sus cables de fibra óptica y hardware de red infrautilizados puede contribuir a la red DoubleZero. Los contribuidores de red deben proporcionar ancho de banda dedicado entre dos puntos, operar dispositivos compatibles con DoubleZero (DZDs) en cada extremo y una conexión a la internet pública en cada extremo. Los contribuidores de red también deben ejecutar el software de DoubleZero en cada DZD para proporcionar servicios como multidifusión, búsqueda de usuarios y filtrado en el borde. -El contrato inteligente de DoubleZero es la piedra angular para garantizar que la red mantenga enlaces de alta calidad que puedan medirse e integrarse en la topología, permitiendo que nuestros controladores de red desarrollen la ruta de extremo a extremo más eficiente entre nuestros diferentes usuarios y puntos finales. Tras la ejecución del contrato inteligente y el despliegue del equipo de red y el ancho de banda, una entidad se clasifica como contribuidor de red. Consulte [Economía de DoubleZero](https://economics.doublezero.xyz/overview) para comprender mejor la economía detrás de participar en DoubleZero como contribuidor de red. +El contrato inteligente de DoubleZero es la piedra angular para garantizar que la red mantenga enlaces de alta calidad que puedan ser medidos e integrados en la topología, permitiendo a nuestros controladores de red desarrollar la ruta más eficiente de extremo a extremo entre nuestros diferentes usuarios y puntos finales. Tras la ejecución del contrato inteligente y el despliegue del equipo de red y el ancho de banda, una entidad se clasifica como contribuidor de red. Consulte [DoubleZero Economics](https://economics.doublezero.xyz/overview) para comprender mejor la economía detrás de participar en DoubleZero como contribuidor de red. --- @@ -16,27 +16,27 @@ El contrato inteligente de DoubleZero es la piedra angular para garantizar que l - Ancho de banda dedicado que pueda proporcionar conectividad IPv4 y un MTU de 2048 bytes entre dos centros de datos - Hardware de Dispositivo DoubleZero (DZD) compatible con el protocolo DoubleZero -- Conectividad a internet y a otros contribuidores de red DoubleZero -- Instalación del software DoubleZero en el DZD +- Conectividad a internet y a otros contribuidores de la red DoubleZero +- Instalación del software de DoubleZero en el DZD ## Guía de Inicio Rápido -Como contribuidor de red, la forma más sencilla de comenzar en DoubleZero es identificando capacidad en su red que pueda dedicarse a DoubleZero. Una vez identificada, los DZDs deben desplegarse, facilitando la red superpuesta de DoubleZero que solo requiere conectividad IPv4 y un MTU mínimo de 2048 bytes como dependencias de la red del contribuidor. +Como contribuidor de red, la forma más sencilla de comenzar en DoubleZero es identificando capacidad en su red que pueda dedicarse a DoubleZero. Una vez identificada, se deben desplegar los DZDs, facilitando la red superpuesta de DoubleZero que solo requiere alcanzabilidad IPv4 y un MTU mínimo de 2048 bytes como dependencias de la red del contribuidor. -La Figura 1 destaca el modelo más simple para contribuir ancho de banda y servicios de envío y procesamiento de paquetes. Se despliega un DZD en cada centro de datos, interfazando con la red interna del contribuidor para proporcionar conectividad WAN de DoubleZero. Esto se complementa con internet local, típicamente una solución de Acceso Directo a Internet (DIA), que se utiliza como puntos de acceso para los usuarios de DoubleZero. Si bien se espera que DIA sea la opción preferida para facilitar el acceso a los usuarios de DoubleZero, son posibles numerosos modelos de conectividad, por ejemplo, cableado físico a servidores, extensión de fabric de red, etc. Nos referimos a estas opciones como Elige Tu Propia Aventura (CYOA), proporcionando al contribuidor flexibilidad para conectar usuarios locales o remotos de la manera que mejor se adapte a sus políticas de red internas. +La Figura 1 destaca el modelo más simple para contribuir ancho de banda y servicios de envío y procesamiento de paquetes. Se despliega un DZD en cada centro de datos, interfazándose con la red interna del contribuidor para proporcionar conectividad WAN de DoubleZero. Esto se complementa con internet local, típicamente una solución de Acceso Directo a Internet (DIA), que se utiliza como puntos de acceso para los usuarios de DoubleZero. Si bien se espera que DIA sea la opción preferida para facilitar el acceso a los usuarios de DoubleZero, son posibles numerosos modelos de conectividad, por ejemplo, cableado físico a servidores, extensión de fabric de red, etc. Nos referimos a estas opciones como Elige Tu Propia Aventura (CYOA), proporcionando al contribuidor flexibilidad para conectar usuarios locales o remotos de la manera que mejor se adapte a sus políticas de red interna. Como con cualquier red, la alcanzabilidad es una parte fundamental de la arquitectura, ya que los contribuidores de red no pueden vivir aislados. Por lo tanto, el DZD *debe* tener un enlace a un DoubleZero Exchange (DZX) para crear una red contigua entre los participantes.
![Image title](images/figure1.png){ width="800" } -
Figura 1: Contribución de Ancho de Banda de Red DoubleZero Entre 2 Centros de Datos - Contribuidor Único
+
Figura 1: Contribución de Ancho de Banda a la Red DoubleZero Entre 2 Centros de Datos - Contribuidor Único
### Ejemplos de Contribuciones Las formas en que un contribuidor de red puede ampliar sus contribuciones a DoubleZero son muchas, incluyendo: -- Mejorar las características de rendimiento de sus contribuciones existentes: aumentar ancho de banda, reducir latencia +- Mejorar las características de rendimiento de sus contribuciones existentes: aumentar el ancho de banda, reducir la latencia - Agregar múltiples enlaces entre los mismos centros de datos - Agregar un nuevo enlace desde un centro de datos existente a un nuevo centro de datos - Agregar un nuevo enlace independiente entre dos nuevos centros de datos @@ -44,38 +44,38 @@ Las formas en que un contribuidor de red puede ampliar sus contribuciones a Doub #### Ejemplo 1: Contribuidor Único, 3 Centros de Datos, Dos Enlaces
![Image title](images/figure2.png){ width="800" } -
Figura 2: Contribución de Ancho de Banda de Red DoubleZero Entre 3 Centros de Datos - Contribuidor Único
+
Figura 2: Contribución de Ancho de Banda a la Red DoubleZero Entre 3 Centros de Datos - Contribuidor Único
-Un solo DZD puede soportar múltiples enlaces contribuidos a DoubleZero. La Figura 2 ilustra una topología potencial si un solo centro de datos, denominado como 1, termina ancho de banda hacia dos centros de datos remotos diferentes, 2 y 3. En este escenario, cada centro de datos contiene solo 1 DZD. Todos los DZDs utilizan DIA para puntos de acceso de usuarios como su interfaz CYOA. +Un solo DZD puede soportar múltiples enlaces contribuidos a DoubleZero. La Figura 2 ilustra una topología potencial si un solo centro de datos, denominado 1, termina ancho de banda hacia dos centros de datos remotos diferentes, 2 y 3. En este escenario, cada centro de datos contiene solo 1 DZD. Todos los DZDs utilizan DIA para los puntos de acceso de usuarios como su interfaz CYOA. #### Ejemplo 2: Contribuidor Único, 3 Centros de Datos, Tres Enlaces -La Figura 3 describe la topología de DoubleZero cuando un contribuidor único despliega tres enlaces en una topología triangular entre 3 centros de datos. En un escenario similar al ejemplo 1, se despliega un solo DZD en los centros de datos 1, 2 y 3, cada uno soportando 2 enlaces de red independientes. La topología resultante es un triángulo o anillo entre centros de datos. +La Figura 3 describe la topología de DoubleZero cuando un solo contribuidor despliega tres enlaces en una topología triangular entre 3 centros de datos. En un escenario similar al ejemplo 1, se despliega un solo DZD en los centros de datos 1, 2 y 3, cada uno soportando 2 enlaces de red independientes. La topología resultante es un triángulo o anillo entre centros de datos.
![Image title](images/figure3.png){ width="800" } -
Figura 3: Contribución de Ancho de Banda de Red DoubleZero Entre 3 Centros de Datos - Contribuidor Único
+
Figura 3: Contribución de Ancho de Banda a la Red DoubleZero Entre 3 Centros de Datos - Contribuidor Único
### DoubleZero Exchange -La creación de una red contigua es un bloque fundamental de la arquitectura de DoubleZero. Los contribuidores se interconectan a través de un DoubleZero Exchange (DZX) dentro de un área metropolitana, que es una ciudad como Nueva York (NYC), Londres (LON) o Tokio (TYO). Un DZX es un fabric de red similar a un Internet Exchange, que permite peering e intercambio de rutas. +La creación de una red contigua es un componente fundamental de la arquitectura de DoubleZero. Los contribuidores se interconectan a través de un DoubleZero Exchange (DZX) dentro de un área metropolitana, que es una ciudad como Nueva York (NYC), Londres (LON) o Tokio (TYO). Un DZX es un fabric de red similar a un Internet Exchange, que permite el peering y el intercambio de rutas. En la figura 4, el contribuidor de red 1 opera en los centros de datos 1, 2 y 3, mientras que el contribuidor de red 2 opera en los centros de datos 2, 4 y 5. Al interconectarse en el centro de datos 2, el alcance de la red DoubleZero aumenta a 5 centros de datos contiguos.
![Image title](images/figure4.png){ width="1000" } -
Figura 4: Contribución de Ancho de Banda de Red DoubleZero Entre 2 Contribuidores de Ancho de Banda de Red
+
Figura 4: Contribución de Ancho de Banda a la Red DoubleZero Entre 2 Contribuidores de Ancho de Banda de Red
### Opciones de Contribución de Ancho de Banda -DoubleZero requiere que un contribuidor de red ofrezca conectividad integrada mediante un perfil garantizado de ancho de banda, latencia y jitter entre DZDs en dos centros de datos de terminación, expresado a través de un contrato inteligente. DoubleZero no establece cómo un contribuidor de red implementa su contribución; sin embargo, en las siguientes secciones proporcionamos opciones indicativas para uso a su entera discreción. +DoubleZero requiere que un contribuidor de red ofrezca conectividad integrada mediante un perfil garantizado de ancho de banda, latencia y jitter entre los DZDs en dos centros de datos de terminación, expresado a través de un contrato inteligente. DoubleZero no impone cómo un contribuidor de red implementa su contribución; sin embargo, en las siguientes secciones proporcionamos opciones indicativas para su uso a su entera discreción. Áreas importantes a considerar para un contribuidor de red podrían ser: -- Capacidad de garantizar el rendimiento de red del servicio DoubleZero: ancho de banda, latencia y jitter +- Capacidad para garantizar el rendimiento de red del servicio DoubleZero: ancho de banda, latencia y jitter - Segregación de sus servicios de red internos existentes - Conflictos de direccionamiento IPv4, específicamente con el espacio de direcciones del underlay de túnel - Tiempo de actividad y disponibilidad @@ -84,34 +84,34 @@ DoubleZero requiere que un contribuidor de red ofrezca conectividad integrada me #### Ancho de Banda de Capa 1
![Image title](images/figure5.png){ width="800" } -
Figura 5: Servicios Ópticos de Capa 1
+
Figura 5: Servicios Ópticos de Capa 1
-El ancho de banda de Capa 1, descrito más formalmente como servicios de longitud de onda, puede verse como capacidad dedicada aprovisionada sobre una infraestructura óptica existente, como DWDM, CWDM o mediante multiplexores ópticos (MUX). En la figura 5, los DZDs utilizan una óptica coloreada que se cablea a un MUX L1, el cual intercala la longitud de onda del DZD en una fibra oscura existente. +El ancho de banda de Capa 1, descrito más formalmente como servicios de longitud de onda, puede contemplar capacidad dedicada aprovisionada sobre una infraestructura óptica existente, como DWDM, CWDM o mediante multiplexores ópticos (MUX). En la figura 5, los DZDs utilizan una óptica coloreada que se cablea a un MUX L1, el cual intercala la longitud de onda del DZD sobre una fibra oscura existente. -Esta solución tiene numerosos beneficios para los contribuidores de red que ya operan una red core existente. Los cambios operativos iterativos, así como los requisitos adicionales de CAPEX y OPEX, son modestos. Esta opción es particularmente robusta para ofrecer segregación de los servicios de red del contribuidor. +Esta solución tiene numerosos beneficios para los contribuidores de red que ya operan una red troncal existente. Los cambios operativos iterativos, así como los requisitos adicionales de CAPEX y OPEX, son modestos. Esta opción es particularmente robusta en ofrecer segregación de los servicios de red del contribuidor. -#### Ancho de Banda de Conmutación de Paquetes +#### Ancho de Banda Conmutado por Paquetes -Las redes de conmutación de paquetes pueden considerarse una red empresarial típica, ejecutando protocolos estándar de enrutamiento y conmutación que soportan aplicaciones de negocio. Existen numerosas tecnologías de red que logran conectividad, por ejemplo, extensiones de capa 2 (L2) utilizando etiquetas VLAN. +Las redes conmutadas por paquetes pueden considerarse una red empresarial típica, que ejecuta protocolos estándar de enrutamiento y conmutación que soportan aplicaciones de negocio. Existen numerosas tecnologías de red que logran conectividad, por ejemplo, extensiones de capa 2 (L2) usando etiquetas VLAN. ##### Extensión L2
![Image title](images/figure6.png){ width="800" } -
Figura 6: Redes de Conmutación de Paquetes - Extensión L2
+
Figura 6: Redes Conmutadas por Paquetes - Extensión L2
-Una extensión L2 como se muestra en la Figura 6 puede facilitarse mediante etiquetado VLAN. El puerto de un DZD puede cablearse al switch de red interna del contribuidor, con el puerto del switch configurado como puerto de acceso en, por ejemplo, VLAN 10. A través del etiquetado 802.1q, esta VLAN puede transportarse a través de múltiples saltos de switch en la red del contribuidor, terminando en el switch que interfaza con el DZD remoto. +Una extensión L2 como se muestra en la Figura 6 puede facilitarse mediante etiquetado VLAN. El puerto de un DZD puede cablearse al switch de red interna del contribuidor, con el puerto del switch configurado como puerto de acceso en, por ejemplo, VLAN 10. A través del etiquetado 802.1q, esta VLAN puede transportarse a través de múltiples saltos de switch en la red del contribuidor, terminando en el switch que se interfaza con el DZD remoto. -Esta solución se beneficia de ser ampliamente soportada y relativamente fácil de implementar, al tiempo que crea segmentación entre DoubleZero y los servicios internos de capa 3. El ancho de banda puede controlarse basándose en la velocidad de interfaz del switch o router interno del contribuidor. Se debe prestar cuidadosa consideración al rendimiento a través de la red L2 interna compartida mediante tecnologías como Calidad de Servicio (QoS) u otras políticas de gestión de tráfico. Sin embargo, las inversiones adicionales de CAPEX y OPEX deberían ser modestas si existe capacidad disponible dentro de la red core del contribuidor. +Esta solución se beneficia de ser ampliamente soportada y relativamente fácil de implementar, al tiempo que crea segmentación entre DoubleZero y los servicios internos de capa 3. El ancho de banda puede controlarse según la velocidad de interfaz del switch o router interno del contribuidor. Se debe prestar especial atención al rendimiento a través de la red L2 interna compartida mediante tecnologías como Calidad de Servicio (QoS) u otras políticas de gestión de tráfico. Sin embargo, las inversiones adicionales de CAPEX y OPEX deberían ser modestas si existe capacidad disponible dentro de la red troncal del contribuidor. #### Ancho de Banda Dedicado de Terceros
![Image title](images/figure7.png){ width="800" } -
Figura 7: Ancho de Banda Dedicado de Terceros
+
Figura 7: Ancho de Banda Dedicado de Terceros
-Si bien reutilizar capacidad disponible será atractivo para muchos contribuidores de red, también se puede dedicar ancho de banda recién adquirido a DoubleZero. En tal escenario, el DZD se conectaría directamente al operador de terceros sin que ningún dispositivo interno del contribuidor esté en línea (figura 7). +Si bien reutilizar la capacidad disponible será atractivo para muchos contribuidores de red, también es posible dedicar ancho de banda recién adquirido a DoubleZero. En tal escenario, el DZD se conectaría directamente al operador de terceros sin que ningún dispositivo interno del contribuidor se interponga (figura 7). Esta opción es atractiva ya que garantiza ancho de banda dedicado para DoubleZero, es operativamente simple y asegura una segmentación completa de cualquier otro servicio de red. Esta opción probablemente tendrá el mayor incremento de OPEX y requiere nuevos contratos de servicio con operadores de terceros. @@ -123,41 +123,41 @@ Esta opción es atractiva ya que garantiza ancho de banda dedicado para DoubleZe Tenga en cuenta que las cantidades a continuación reflejan el equipo necesario en dos centros de datos, es decir, el hardware total requerido para desplegar 1 cable de fibra óptica para contribución de ancho de banda. -??? warning "*Todas las FPGAs están sujetas a pruebas finales. Las contribuciones de 10G pueden ser soportadas usando switches Arista 7130LBR con FPGAs duales Virtex® UltraScale+™ integradas (si tiene alguna pregunta, DoubleZero Foundation / Malbec Labs estarán encantados de proporcionar más información)." +??? warning "*Todas las FPGAs están sujetas a pruebas finales. Las contribuciones de 10G pueden ser soportadas utilizando switches Arista 7130LBR con FPGAs Virtex® UltraScale+™ duales integradas (si tiene alguna pregunta, DoubleZero Foundation / Malbec Labs estarán encantados de proporcionar más información)." #### Requisitos de Función y Puertos -| Función | Velocidad del Puerto | Requisito DZ | CANT | Nota | +| Función | Velocidad de Puerto | Requisito DZ | CANT | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Ancho de Banda Privado | 100G | Sí | 1 | | | Acceso Directo a Internet (DIA) | 10G | Sí | 2 | | | DoubleZero eXchange (DZX) | 100G | Sí* | 1 | Debe soportarse una vez que más de 3 proveedores operen en la misma área metropolitana; antes de esto, se pueden usar cross-connects u otros acuerdos de peering para interconectarse con otros proveedores. | -| Gestión | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | -| Consola | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | +| Gestión | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | +| Consola | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | #### Hardware de Red DZD -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | Sí | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son desafiantes. | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son difíciles. | --- #### Ópticas - 100G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | El cableado y la elección de óptica quedan a discreción del contribuidor. Se requiere 100G para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | El cableado y la elección de ópticas quedan a discreción del contribuidor. Se requiere 100G para conectar FPGAs. | --- #### Ópticas - 10G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | No | 2 | El cableado y la elección de óptica quedan a discreción del contribuidor. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 2 | El cableado y la elección de óptica quedan a discreción del contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | No | 2 | El cableado y la elección de ópticas quedan a discreción del contribuidor. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 2 | El cableado y la elección de ópticas quedan a discreción del contribuidor. | --- @@ -165,9 +165,9 @@ Tenga en cuenta que las cantidades a continuación reflejan el equipo necesario | Direccionamiento IP | Tamaño Mínimo de Subred | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable a través de DIA. Es posible que eliminemos esta necesidad con el tiempo. | +| Public IPv4 | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable vía DIA. Es posible que eliminemos la necesidad de esto con el tiempo. | -Asegúrese de que el pool completo /29 esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse a través de un pool de direcciones diferente. +Asegúrese de que el pool /29 completo esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse mediante un pool de direcciones diferente. ### Contribución de Ancho de Banda de 10Gbps @@ -175,48 +175,48 @@ Tenga en cuenta que las cantidades reflejan el equipo de dos centros de datos, e #### Requisitos de Función y Puertos -| Función | Velocidad del Puerto | Requisito DZ | CANT | Nota | +| Función | Velocidad de Puerto | Requisito DZ | CANT | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Ancho de Banda Privado | 10G | Sí | 1 | | | Acceso Directo a Internet (DIA) | 10G | Sí | 2 | | | DoubleZero eXchange (DZX) | 100G | Sí* | 1 | Debe soportarse una vez que más de 3 proveedores operen en la misma área metropolitana; antes de esto, se pueden usar cross-connects u otros acuerdos de peering para interconectarse con otros proveedores. | -| Gestión | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | -| Consola | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | +| Gestión | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | +| Consola | | No | 1 | Determinado por las políticas internas de gestión del contribuidor. | --- #### Hardware -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474* | Sí | 4 | | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son desafiantes. | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sí | 2 | Pueden ser posibles alternativas si los tiempos de entrega son difíciles. | --- #### Ópticas - 100G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | El cableado y la elección de óptica quedan a discreción del contribuidor. Se requiere 100G para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | El cableado y la elección de ópticas quedan a discreción del contribuidor. Se requiere 100G para conectar FPGAs. | --- #### Ópticas - 10G -| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | +| Fabricante | Modelo | Número de Parte | Requisito DZ | CANT | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | No | 4 | El cableado y la elección de óptica quedan a discreción del contribuidor. | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 4 | El cableado y la elección de óptica quedan a discreción del contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | No | 4 | El cableado y la elección de ópticas quedan a discreción del contribuidor. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 4 | El cableado y la elección de ópticas quedan a discreción del contribuidor. | --- #### Direccionamiento IP | Direccionamiento IP | Tamaño Mínimo de Subred | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable a través de DIA. Es posible que eliminemos esta necesidad con el tiempo. | +| Public IPv4 | /29 | Sí (para DZDs de borde/híbridos) | Debe ser enrutable vía DIA. Es posible que eliminemos la necesidad de esto con el tiempo. | -Asegúrese de que el pool completo /29 esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse a través de un pool de direcciones diferente. +Asegúrese de que el pool /29 completo esté disponible para el protocolo DZ. Cualquier requisito de direccionamiento punto a punto, por ejemplo, en interfaces DIA, debe gestionarse mediante un pool de direcciones diferente. ### Requisitos del Centro de Datos @@ -229,9 +229,9 @@ Las cifras a continuación son **por DZD**, es decir, por centro de datos. Una c | Elemento | Unidades de rack | Necesario | |------|-----------|--------| | Switch DZD (Arista 7280CR3A-32S o 7130LBR) | 1U | Ahora | -| Dispositivo de filtrado en el borde | 1U | Más adelante, solo en dispositivos de borde e híbridos | +| Appliance de filtrado en el borde | 1U | Posteriormente, solo en dispositivos de borde e híbridos | -**Reserve 2U por DZD.** Una unidad está en uso hoy. Mantenga la segunda libre para que el dispositivo de filtrado en el borde pueda instalarse junto al switch sin necesidad de mover el rack. Deje espacio para el flujo de aire y la gestión de cables según lo requiera su instalación. +**Reserve 2U por DZD.** Una unidad está en uso hoy. Mantenga la segunda libre para que el appliance de filtrado en el borde pueda instalarse junto al switch sin necesidad de mover el rack. Deje espacio para flujo de aire y gestión de cables según lo requiera su instalación. ##### Energía @@ -240,17 +240,17 @@ Las cifras a continuación son **por DZD**, es decir, por centro de datos. Una c | Arista 7280CR3A-32S | ~300 W | | Ópticas, por QSFP 100G | ~5 W | -**Solicite 2 kW por DZD, distribuidos en dos alimentaciones independientes.** Dimensione cada alimentación para soportar la carga completa por sí sola. El switch ejecuta fuentes de alimentación redundantes, y después de una falla de alimentación, una de ellas puede ser todo lo que le quede. +**Solicite 2 kW por DZD, distribuidos entre dos alimentaciones independientes.** Dimensione cada alimentación para soportar la carga completa por sí sola. El switch cuenta con fuentes de alimentación redundantes, y tras una falla de alimentación, una de ellas puede ser todo lo que le quede. -2 kW es cómodo en lugar de ajustado. Un DZD solo con switch, que es lo que ejecuta casi todo despliegue hoy en día, consume bastante menos de 500 W con todas sus ópticas encendidas. El resto de los 2 kW está reservado para el dispositivo de filtrado en el borde, que contiene las FPGAs y se instala posteriormente. +2 kW es cómodo en lugar de ajustado. Un DZD solo con switch, que es lo que ejecuta casi todo despliegue hoy, consume bastante menos de 500 W con todas sus ópticas encendidas. El resto de los 2 kW está reservado para el appliance de filtrado en el borde, que contiene las FPGAs y se instala posteriormente. !!! warning "No solicite energía en exceso" - Usted paga por la energía que reserva, la consuma o no. Un DZD es una sola unidad de rack de conmutación, no un chasis de cómputo, por lo que consume mucho menos de lo que su posición en rack podría suministrar. Reservar más de 2 kW por DZD significa pagar por capacidad que permanece inactiva. + Usted paga por la energía que reserva, la consuma o no. Un DZD es una sola unidad de rack de conmutación, no un chasis de cómputo, por lo que consume mucho menos de lo que su posición en el rack podría suministrar. Reservar más de 2 kW por DZD significa pagar por capacidad que permanece inactiva. -!!! note "Verifique su propio hardware antes de realizar el pedido" - Estas son cifras orientativas de nuestros propios despliegues. Su consumo real depende de la configuración de su fuente de alimentación, cuántos puertos encienda y qué ópticas elija. Confirme contra las especificaciones de la fuente de alimentación en la hoja de datos del fabricante para el hardware exacto que compre. +!!! note "Verifique su propio hardware antes de hacer el pedido" + Estas son cifras orientativas de nuestros propios despliegues. Su consumo real depende de la configuración de su fuente de alimentación, cuántos puertos encienda y qué ópticas elija. Confirme con las especificaciones de potencia en la hoja de datos del fabricante para el hardware exacto que adquiera. - Tampoco reduzca el pedido al mínimo indispensable. La energía debe estar disponible en el rack, y agregar una alimentación más tarde generalmente implica un nuevo pedido con la instalación, lo cual puede tomar semanas. + Tampoco ajuste el pedido al mínimo indispensable. La energía debe estar disponible en el rack, y agregar una alimentación después generalmente implica un nuevo pedido con la instalación, lo cual puede tomar semanas. --- diff --git a/docs/contribute.fr.md b/docs/contribute.fr.md index 06dc331..aa1891b 100644 --- a/docs/contribute.fr.md +++ b/docs/contribute.fr.md @@ -1,109 +1,109 @@ --- -description: Exigences et architecture en matière de matériel, de bande passante et de connectivité pour contribuer en capacité au réseau DoubleZero. +description: Exigences matérielles, de bande passante et de connectivité, ainsi que l'architecture pour contribuer de la capacité au réseau DoubleZero. --- -# Exigences et architecture des contributeurs +# Exigences et architecture pour les contributeurs ## Résumé Toute personne souhaitant monétiser ses câbles à fibre optique et son matériel réseau sous-utilisés peut contribuer au réseau DoubleZero. Les contributeurs réseau doivent fournir une bande passante dédiée entre deux points, exploiter des appareils compatibles DoubleZero (DZD) à chaque extrémité, ainsi qu'une connexion à l'internet public à chaque extrémité. Les contributeurs réseau doivent également exécuter le logiciel DoubleZero sur chaque DZD pour fournir des services tels que le multicast, la recherche d'utilisateurs et le filtrage en périphérie. -Le contrat intelligent DoubleZero est la pierre angulaire garantissant que le réseau maintient des liens de haute qualité pouvant être mesurés et intégrés dans la topologie, permettant à nos contrôleurs réseau de développer le chemin de bout en bout le plus efficace entre nos différents utilisateurs et points de terminaison. Lors de l'exécution du contrat intelligent et du déploiement de l'équipement réseau et de la bande passante, une entité est classée comme contributeur réseau. Consultez [DoubleZero Economics](https://economics.doublezero.xyz/overview) pour mieux comprendre les aspects économiques de la participation à DoubleZero en tant que contributeur réseau. +Le contrat intelligent DoubleZero est la pierre angulaire garantissant que le réseau maintient des liaisons de haute qualité pouvant être mesurées et intégrées dans la topologie, permettant à nos contrôleurs réseau de développer le chemin de bout en bout le plus efficace entre nos différents utilisateurs et points de terminaison. Après l'exécution du contrat intelligent et le déploiement de l'équipement réseau et de la bande passante, une entité est classée comme contributeur réseau. Consultez [DoubleZero Economics](https://economics.doublezero.xyz/overview) pour mieux comprendre les aspects économiques de la participation à DoubleZero en tant que contributeur réseau. --- -## Exigences pour devenir contributeur au réseau DoubleZero +## Exigences pour devenir contributeur réseau DoubleZero - Bande passante dédiée pouvant fournir une connectivité IPv4 et un MTU de 2048 octets entre deux centres de données - Matériel DoubleZero Device (DZD) compatible avec le protocole DoubleZero -- Connectivité à Internet et aux autres contributeurs du réseau DoubleZero +- Connectivité à internet et aux autres contributeurs réseau DoubleZero - Installation du logiciel DoubleZero sur le DZD ## Guide de démarrage rapide -En tant que contributeur réseau, la manière la plus simple de commencer avec DoubleZero est d'identifier la capacité de votre réseau pouvant être dédiée à DoubleZero. Une fois identifiée, les DZD doivent être déployés, facilitant le réseau overlay DoubleZero qui ne nécessite que l'accessibilité IPv4 et un MTU minimum de 2048 octets comme dépendances du réseau du contributeur. +En tant que contributeur réseau, la façon la plus simple de commencer avec DoubleZero est d'identifier la capacité dans votre réseau pouvant être dédiée à DoubleZero. Une fois identifiée, les DZD doivent être déployés, facilitant le réseau overlay DoubleZero qui ne nécessite que la joignabilité IPv4 et un MTU minimum de 2048 octets comme dépendances du réseau du contributeur. -La figure 1 illustre le modèle le plus simple pour la contribution en bande passante et les services d'envoi et de traitement de paquets. Un DZD est déployé dans chaque centre de données, s'interfaçant avec le réseau interne du contributeur réseau pour fournir la connectivité WAN DoubleZero. Cela est complété par un accès Internet local, généralement une solution d'accès Internet direct (DIA), utilisée comme points d'entrée pour les utilisateurs de DoubleZero. Bien que le DIA soit l'option privilégiée pour faciliter l'accès aux utilisateurs de DoubleZero, de nombreux modèles de connectivité sont possibles, par exemple : câblage physique vers les serveurs, extension de la fabric réseau, etc. Nous désignons ces options sous le nom de Choose Your Own Adventure (CYOA), offrant au contributeur la flexibilité de connecter des utilisateurs locaux ou distants de la manière la mieux adaptée à leurs politiques réseau internes. +La figure 1 illustre le modèle le plus simple pour contribuer de la bande passante et des services d'envoi et de traitement de paquets. Un DZD est déployé dans chaque centre de données, s'interfaçant avec le réseau interne du contributeur réseau pour fournir la connectivité WAN DoubleZero. Ceci est complété par un accès internet local, généralement une solution d'accès internet direct (DIA), utilisée comme point d'entrée pour les utilisateurs de DoubleZero. Bien qu'il soit prévu que le DIA soit l'option privilégiée pour faciliter l'accès aux utilisateurs de DoubleZero, de nombreux modèles de connectivité sont possibles, par exemple le câblage physique aux serveurs, l'extension de la fabric réseau, etc. Nous désignons ces options sous le nom de Choose Your Own Adventure (CYOA), offrant au contributeur la flexibilité de connecter les utilisateurs locaux ou distants de la manière la mieux adaptée à leurs politiques réseau internes. -Comme pour tout réseau, l'accessibilité est une partie fondamentale de l'architecture, car les contributeurs réseau ne peuvent pas vivre de manière isolée. À ce titre, le DZD *doit* disposer d'un lien vers un DoubleZero Exchange (DZX) pour créer un réseau contigu entre les participants. +Comme pour tout réseau, la joignabilité est une partie fondamentale de l'architecture, car les contributeurs réseau ne peuvent pas vivre en isolation. À ce titre, le DZD *doit* avoir une liaison vers un DoubleZero Exchange (DZX) pour créer un réseau contigu entre les participants.
![Image title](images/figure1.png){ width="800" } -
Figure 1 : Contribution en bande passante au réseau DoubleZero entre 2 centres de données - Contributeur unique
+
Figure 1 : Contribution de bande passante réseau DoubleZero entre 2 centres de données - Contributeur unique
### Exemples de contributions -Les moyens par lesquels un contributeur réseau peut accroître ses contributions à DoubleZero sont nombreux, notamment : +Les façons dont un contributeur réseau peut développer ses contributions DoubleZero sont nombreuses, notamment : - Améliorer les caractéristiques de performance de ses contributions existantes : augmenter la bande passante, réduire la latence -- Ajouter plusieurs liens entre les mêmes centres de données -- Ajouter un nouveau lien d'un centre de données existant vers un nouveau centre de données -- Ajouter un nouveau lien indépendant entre deux nouveaux centres de données +- Ajouter plusieurs liaisons entre les mêmes centres de données +- Ajouter une nouvelle liaison d'un centre de données existant vers un nouveau centre de données +- Ajouter une nouvelle liaison indépendante entre deux nouveaux centres de données -#### Exemple 1 : Contributeur unique, 3 centres de données, deux liens +#### Exemple 1 : Contributeur unique, 3 centres de données, deux liaisons
![Image title](images/figure2.png){ width="800" } -
Figure 2 : Contribution en bande passante au réseau DoubleZero entre 3 centres de données - Contributeur unique
+
Figure 2 : Contribution de bande passante réseau DoubleZero entre 3 centres de données - Contributeur unique
-Un seul DZD peut prendre en charge plusieurs liens contribués à DoubleZero. La figure 2 illustre une topologie potentielle si un seul centre de données, désigné comme 1, termine la bande passante vers deux centres de données distants différents, 2 et 3. Dans ce scénario, chaque centre de données contient un seul DZD. Tous les DZD utilisent le DIA comme points d'entrée utilisateurs pour leur interface CYOA. +Un seul DZD peut prendre en charge plusieurs liaisons contribuées à DoubleZero. La figure 2 illustre une topologie potentielle si un seul centre de données, désigné comme 1, termine la bande passante vers deux centres de données distants différents, 2 et 3. Dans ce scénario, chaque centre de données contient un seul DZD. Tous les DZD utilisent le DIA pour les points d'entrée utilisateurs comme interface CYOA. -#### Exemple 2 : Contributeur unique, 3 centres de données, trois liens +#### Exemple 2 : Contributeur unique, 3 centres de données, trois liaisons -La figure 3 décrit la topologie DoubleZero lorsqu'un contributeur unique déploie trois liens dans une topologie en triangle entre 3 centres de données. Dans un scénario similaire à l'exemple 1, un seul DZD est déployé dans les centres de données 1, 2 et 3, chacun supportant 2 liens réseau indépendants. La topologie résultante est un triangle ou un anneau entre les centres de données. +La figure 3 décrit la topologie DoubleZero lorsqu'un contributeur unique déploie trois liaisons dans une topologie en triangle entre 3 centres de données. Dans un scénario similaire à l'exemple 1, un seul DZD est déployé dans les centres de données 1, 2 et 3, chacun prenant en charge 2 liaisons réseau indépendantes. La topologie résultante est un triangle ou anneau entre les centres de données.
![Image title](images/figure3.png){ width="800" } -
Figure 3 : Contribution en bande passante au réseau DoubleZero entre 3 centres de données - Contributeur unique
+
Figure 3 : Contribution de bande passante réseau DoubleZero entre 3 centres de données - Contributeur unique
### DoubleZero Exchange -La création d'un réseau contigu est un élément fondamental de l'architecture DoubleZero. Les contributeurs s'interfacent via un DoubleZero Exchange (DZX) au sein d'une zone métropolitaine, c'est-à-dire une ville telle que New York (NYC), Londres (LON) ou Tokyo (TYO). Un DZX est une fabric réseau similaire à un point d'échange Internet, permettant le peering et l'échange de routes. +La création d'un réseau contigu est un élément fondamental de l'architecture DoubleZero. Les contributeurs s'interconnectent via un DoubleZero Exchange (DZX) au sein d'une zone métropolitaine, qui est une ville telle que New York (NYC), Londres (LON) ou Tokyo (TYO). Un DZX est une fabric réseau similaire à un point d'échange internet, permettant le peering et l'échange de routes. Dans la figure 4, le contributeur réseau 1 opère dans les centres de données 1, 2 et 3, tandis que le contributeur réseau 2 opère dans les centres de données 2, 4 et 5. En s'interconnectant dans le centre de données 2, la portée du réseau DoubleZero s'étend à 5 centres de données contigus.
![Image title](images/figure4.png){ width="1000" } -
Figure 4 : Contribution en bande passante au réseau DoubleZero entre 2 contributeurs en bande passante réseau
+
Figure 4 : Contribution de bande passante réseau DoubleZero entre 2 contributeurs de bande passante réseau
-### Options de contribution en bande passante +### Options de contribution de bande passante -DoubleZero exige qu'un contributeur réseau offre une connectivité intégrée via un profil garanti de bande passante, de latence et de gigue entre les DZD de deux centres de données de terminaison, exprimé via un contrat intelligent. DoubleZero ne prescrit pas la manière dont un contributeur réseau met en œuvre sa contribution ; cependant, dans les sections suivantes, nous fournissons des options indicatives à utiliser à leur seule discrétion. +DoubleZero exige qu'un contributeur réseau offre une connectivité intégrée via un profil garanti de bande passante, latence et gigue entre les DZD de deux centres de données de terminaison, exprimé via un contrat intelligent. DoubleZero ne prescrit pas la manière dont un contributeur réseau implémente sa contribution ; cependant, dans les sections suivantes, nous fournissons des options indicatives à utiliser à sa seule discrétion. Les domaines importants à considérer pour un contributeur réseau peuvent être : -- Capacité à garantir les performances réseau du service DoubleZero : bande passante, latence et gigue -- Séparation de leurs services réseau internes existants -- Conflits d'adressage IPv4, en particulier avec l'espace d'adressage de l'underlay tunnel -- Disponibilité et temps de fonctionnement -- Considérations CAPEX et OPEX +- La capacité à garantir les performances réseau du service DoubleZero : bande passante, latence et gigue +- La ségrégation par rapport à leurs services réseau internes existants +- Les conflits d'adressage IPv4, spécifiquement avec l'espace d'adressage de l'underlay tunnel +- La disponibilité et le temps de fonctionnement +- Les considérations de CAPEX et OPEX -#### Bande passante de couche 1 +#### Bande passante couche 1
![Image title](images/figure5.png){ width="800" } -
Figure 5 : Services optiques de couche 1
+
Figure 5 : Services optiques couche 1
-La bande passante de couche 1, plus formellement décrite comme des services de longueur d'onde, peut voir une capacité dédiée provisionnée sur une infrastructure optique existante, telle que DWDM, CWDM ou via des multiplexeurs optiques (MUX). Dans la figure 5, les DZD utilisent une optique colorée qui est câblée à un MUX L1, lequel entrelace la longueur d'onde du DZD sur une fibre noire existante. +La bande passante couche 1, plus formellement décrite comme des services de longueur d'onde, peut voir une capacité dédiée provisionnée sur une infrastructure optique existante, telle que DWDM, CWDM ou via des multiplexeurs optiques (MUX). Dans la figure 5, les DZD utilisent une optique colorée câblée à un MUX L1, qui entrelace la longueur d'onde du DZD sur une fibre noire existante. -Cette solution présente de nombreux avantages pour les contributeurs réseau qui exploitent déjà un réseau cœur existant. Les changements opérationnels itératifs, ainsi que les exigences supplémentaires en CAPEX et OPEX, sont modestes. Cette option est particulièrement robuste pour offrir une séparation des services réseau du contributeur. +Cette solution présente de nombreux avantages pour les contributeurs réseau qui exploitent déjà un réseau cœur existant. Les changements opérationnels itératifs, ainsi que les exigences supplémentaires en CAPEX et OPEX, sont modestes. Cette option est particulièrement robuste pour offrir une ségrégation par rapport aux services réseau du contributeur. -#### Bande passante à commutation de paquets +#### Bande passante commutée par paquets -Les réseaux à commutation de paquets peuvent être considérés comme un réseau d'entreprise typique, exécutant des protocoles de routage et de commutation standard supportant des applications métier. De nombreuses technologies réseau permettent d'atteindre la connectivité, par exemple, les extensions de couche 2 (L2) utilisant des tags VLAN. +Les réseaux commutés par paquets peuvent être considérés comme un réseau d'entreprise typique, exécutant des protocoles de routage et de commutation standard prenant en charge les applications métier. De nombreuses technologies réseau permettent d'assurer la connectivité, par exemple, les extensions couche 2 (L2) utilisant des tags VLAN. ##### Extension L2
![Image title](images/figure6.png){ width="800" } -
Figure 6 : Réseaux à commutation de paquets - Extension L2
+
Figure 6 : Réseaux commutés par paquets - Extension L2
-Une extension L2, comme illustrée dans la figure 6, peut être facilitée par le marquage VLAN. Le port d'un DZD peut être câblé au commutateur réseau interne d'un contributeur, avec le port du commutateur configuré comme port d'accès dans, par exemple, le VLAN 10. Via le marquage 802.1q, ce VLAN peut être transporté sur plusieurs sauts de commutateurs sur le réseau du contributeur, se terminant au commutateur interfaçant avec le DZD distant. +Une extension L2 telle qu'illustrée dans la figure 6 peut être facilitée par le marquage VLAN. Le port d'un DZD peut être câblé au commutateur réseau interne d'un contributeur, le port du commutateur étant configuré comme port d'accès dans, par exemple, le VLAN 10. Grâce au marquage 802.1q, ce VLAN peut être transporté sur plusieurs sauts de commutateurs sur le réseau du contributeur, se terminant au commutateur interfacé avec le DZD distant. -Cette solution bénéficie d'une prise en charge large et d'une mise en œuvre relativement facile tout en créant une segmentation entre DoubleZero et les services internes de couche 3. La bande passante peut être contrôlée en fonction de la vitesse d'interface du commutateur ou du routeur interne du contributeur. Une attention particulière doit être portée aux performances sur le réseau L2 interne partagé à travers des technologies telles que la qualité de service (QoS) ou d'autres politiques de gestion du trafic. Cependant, les investissements supplémentaires en CAPEX et OPEX devraient être modestes si une capacité existante est disponible au sein du réseau cœur du contributeur. +Cette solution bénéficie d'un support large et d'une mise en œuvre relativement facile tout en créant une segmentation entre DoubleZero et les services internes de couche 3. La bande passante peut être contrôlée en fonction de la vitesse d'interface du commutateur ou du routeur interne du contributeur. Une attention particulière doit être accordée aux performances à travers le réseau L2 interne partagé via des technologies telles que la qualité de service (QoS) ou d'autres politiques de gestion du trafic. Cependant, les investissements supplémentaires en CAPEX et OPEX devraient être modestes si une capacité existante est disponible au sein du réseau cœur du contributeur. #### Bande passante dédiée tierce
@@ -111,53 +111,53 @@ Cette solution bénéficie d'une prise en charge large et d'une mise en œuvre r
Figure 7 : Bande passante dédiée tierce
-Bien que la réutilisation de la capacité disponible soit attractive pour de nombreux contributeurs réseau, il est également possible de dédier de la bande passante nouvellement acquise à DoubleZero. Dans un tel scénario, le DZD se connecterait directement à l'opérateur tiers sans aucun appareil interne du contributeur en ligne (figure 7). +Bien que la réutilisation de la capacité disponible soit attrayante pour de nombreux contributeurs réseau, il est également possible de dédier une bande passante nouvellement acquise à DoubleZero. Dans un tel scénario, le DZD se connecterait directement à l'opérateur tiers sans qu'aucun équipement interne du contributeur ne soit en ligne (figure 7). -Cette option est attractive car elle assure une bande passante dédiée pour DoubleZero, est simple sur le plan opérationnel et garantit une segmentation complète par rapport à tout autre service réseau. Cette option entraînera probablement la plus forte augmentation d'OPEX et nécessite de nouveaux contrats de service avec des opérateurs tiers. +Cette option est attractive car elle garantit une bande passante dédiée pour DoubleZero, est simple sur le plan opérationnel et assure une segmentation complète par rapport à tout autre service réseau. Cette option entraînera probablement la plus forte augmentation d'OPEX et nécessite de nouveaux contrats de service avec des opérateurs tiers. --- ## Exigences matérielles -### Contribution en bande passante 100 Gbps +### Contribution de bande passante 100 Gbps -Notez que les quantités ci-dessous reflètent l'équipement nécessaire dans deux centres de données, c'est-à-dire le matériel total requis pour déployer 1 câble à fibre optique pour la contribution en bande passante. +Notez que les quantités ci-dessous reflètent l'équipement nécessaire dans deux centres de données, c'est-à-dire le matériel total requis pour déployer 1 câble à fibre optique pour la contribution de bande passante. -??? warning "*Tous les FPGA sont soumis à des tests finaux. Les contributions 10G peuvent être prises en charge à l'aide de commutateurs Arista 7130LBR avec des FPGA Virtex® UltraScale+™ doubles intégrés (si vous avez des questions, DoubleZero Foundation / Malbec Labs se feront un plaisir de fournir plus d'informations).*" +??? warning "*Tous les FPGA sont soumis aux tests finaux. Les contributions 10G peuvent être prises en charge en utilisant des commutateurs Arista 7130LBR avec des FPGA double Virtex® UltraScale+™ intégrés (si vous avez des questions, la DoubleZero Foundation / Malbec Labs se feront un plaisir de fournir plus d'informations).*" -#### Exigences de fonction et de ports +#### Exigences de fonctions et de ports -| Fonction | Vitesse du port | Exigence DZ | QTÉ | Note | +| Fonction | Vitesse de port | Exigence DZ | QTÉ | Note | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Bande passante privée | 100G | Oui | 1 | | -| Accès Internet direct (DIA) | 10G | Oui | 2 | | -| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge dès que plus de 3 fournisseurs opèrent dans la même zone métropolitaine ; avant cela, des interconnexions directes ou d'autres arrangements de peering peuvent être utilisés pour se connecter à d'autres fournisseurs. | -| Gestion | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | +| Bande passante privée | 100G | Oui | 1 | | +| Accès internet direct (DIA) | 10G | Oui | 2 | | +| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge dès que plus de 3 fournisseurs opèrent dans la même zone métropolitaine ; avant cela, des interconnexions directes ou d'autres arrangements de peering peuvent être utilisés pour s'interconnecter avec d'autres fournisseurs. | +| Gestion | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | | Console | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | #### Matériel réseau DZD -| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | Oui | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être possibles si les délais de livraison sont contraignants. | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être envisagées si les délais de livraison sont contraignants. | --- #### Optiques - 100G -| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 16 | Le choix du câblage et des optiques est à la discrétion du contributeur. 100G requis pour connecter les FPGA. | +| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 16 | Le câblage et le choix des optiques sont à la discrétion du contributeur. 100G requis pour connecter les FPGA. | --- #### Optiques - 10G -| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Non | 2 | Le choix du câblage et des optiques est à la discrétion du contributeur. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 2 | Le choix du câblage et des optiques est à la discrétion du contributeur. | +| Arista | 10GBASE-LR | SFP-10G-LR | Non | 2 | Le câblage et le choix des optiques sont à la discrétion du contributeur. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 2 | Le câblage et le choix des optiques sont à la discrétion du contributeur. | --- @@ -165,64 +165,64 @@ Notez que les quantités ci-dessous reflètent l'équipement nécessaire dans de | Adressage IP | Taille minimale du sous-réseau | Exigence DZ | Note | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 publique | /29 | Oui (pour les DZD edge/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | +| Public IPv4 | /29 | Oui (pour les DZD edge/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | -Veuillez vous assurer que l'ensemble du pool /29 est disponible pour le protocole DZ. Tout besoin d'adressage point-à-point, par exemple sur les interfaces DIA, doit être géré via un pool d'adresses différent. +Veuillez vous assurer que l'intégralité du pool /29 est disponible pour le protocole DZ. Toute exigence d'adressage point à point, par exemple sur les interfaces DIA, doit être gérée via un pool d'adresses différent. -### Contribution en bande passante 10 Gbps +### Contribution de bande passante 10 Gbps -Notez que les quantités reflètent l'équipement pour deux centres de données, c'est-à-dire le matériel total requis pour déployer 1 contribution en bande passante. +Notez que les quantités reflètent l'équipement pour deux centres de données, c'est-à-dire le matériel total requis pour déployer 1 contribution de bande passante. -#### Exigences de fonction et de ports +#### Exigences de fonctions et de ports -| Fonction | Vitesse du port | Exigence DZ | QTÉ | Note | +| Fonction | Vitesse de port | Exigence DZ | QTÉ | Note | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Bande passante privée | 10G | Oui | 1 | | -| Accès Internet direct (DIA) | 10G | Oui | 2 | | -| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge dès que plus de 3 fournisseurs opèrent dans la même zone métropolitaine ; avant cela, des interconnexions directes ou d'autres arrangements de peering peuvent être utilisés pour se connecter à d'autres fournisseurs. | -| Gestion | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | +| Bande passante privée | 10G | Oui | 1 | | +| Accès internet direct (DIA) | 10G | Oui | 2 | | +| DoubleZero eXchange (DZX) | 100G | Oui* | 1 | Doit être pris en charge dès que plus de 3 fournisseurs opèrent dans la même zone métropolitaine ; avant cela, des interconnexions directes ou d'autres arrangements de peering peuvent être utilisés pour s'interconnecter avec d'autres fournisseurs. | +| Gestion | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | | Console | | Non | 1 | Déterminé par les propres politiques de gestion interne du contributeur. | --- #### Matériel -| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474* | Oui | 4 | | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être possibles si les délais de livraison sont contraignants. | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Oui | 2 | Des alternatives peuvent être envisagées si les délais de livraison sont contraignants. | --- #### Optiques - 100G -| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 14 | Le choix du câblage et des optiques est à la discrétion du contributeur. 100G requis pour connecter les FPGA. | +| Arista | 100GBASE-LR | QSFP-100G-LR | Non | 14 | Le câblage et le choix des optiques sont à la discrétion du contributeur. 100G requis pour connecter les FPGA. | --- #### Optiques - 10G -| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | +| Fabricant | Modèle | Référence | Exigence DZ | QTÉ | Note | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Non | 4 | Le choix du câblage et des optiques est à la discrétion du contributeur. | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 4 | Le choix du câblage et des optiques est à la discrétion du contributeur. | +| Arista | 10GBASE-LR | SFP-10G-LR | Non | 4 | Le câblage et le choix des optiques sont à la discrétion du contributeur. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Non | 4 | Le câblage et le choix des optiques sont à la discrétion du contributeur. | --- #### Adressage IP | Adressage IP | Taille minimale du sous-réseau | Exigence DZ | Note | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 publique | /29 | Oui (pour les DZD edge/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | +| Public IPv4 | /29 | Oui (pour les DZD edge/hybrides) | Doit être routable via DIA. Nous pourrions éliminer ce besoin au fil du temps. | -Veuillez vous assurer que l'ensemble du pool /29 est disponible pour le protocole DZ. Tout besoin d'adressage point-à-point, par exemple sur les interfaces DIA, doit être géré via un pool d'adresses différent. +Veuillez vous assurer que l'intégralité du pool /29 est disponible pour le protocole DZ. Toute exigence d'adressage point à point, par exemple sur les interfaces DIA, doit être gérée via un pool d'adresses différent. -### Exigences du centre de données +### Exigences relatives au centre de données -#### Exigences d'espace rack et d'alimentation +#### Exigences en espace rack et alimentation -Les chiffres ci-dessous sont **par DZD**, donc par centre de données. Une contribution en bande passante 100G ou 10G place un DZD à chaque extrémité du lien, il faut donc prévoir cela deux fois. +Les chiffres ci-dessous sont **par DZD**, donc par centre de données. Une contribution de bande passante 100G ou 10G place un DZD à chaque extrémité de la liaison, prévoyez donc cela deux fois. ##### Espace rack @@ -240,17 +240,17 @@ Les chiffres ci-dessous sont **par DZD**, donc par centre de données. Une contr | Arista 7280CR3A-32S | ~300 W | | Optiques, par QSFP 100G | ~5 W | -**Commandez 2 kW par DZD, répartis sur deux alimentations indépendantes.** Dimensionnez chaque alimentation pour supporter la charge complète seule. Le commutateur dispose d'alimentations redondantes, et après une défaillance d'alimentation, l'une d'entre elles peut être tout ce qu'il vous reste. +**Commandez 2 kW par DZD, répartis sur deux alimentations indépendantes.** Dimensionnez chaque alimentation pour supporter la charge totale seule. Le commutateur dispose d'alimentations redondantes, et après une panne d'alimentation, l'une d'entre elles pourrait être tout ce qui reste. -2 kW est confortable plutôt que juste. Un DZD composé uniquement d'un commutateur, ce qui correspond à la quasi-totalité des déploiements aujourd'hui, consomme bien moins de 500 W avec toutes ses optiques allumées. Le reste des 2 kW est réservé pour l'appliance de filtrage en périphérie, qui contient les FPGA et sera installée ultérieurement. +2 kW est confortable plutôt que juste. Un DZD avec commutateur uniquement, ce qui correspond à la quasi-totalité des déploiements actuels, consomme bien moins de 500 W avec toutes ses optiques allumées. Le reste des 2 kW est réservé pour l'appliance de filtrage en périphérie, qui contient les FPGA et sera installée ultérieurement. -!!! warning "Ne commandez pas trop de puissance" - Vous payez pour la puissance que vous réservez, que vous la consommiez ou non. Un DZD est une seule unité de rack de commutation, pas un châssis de calcul, il consomme donc bien moins que ce que sa position dans le rack pourrait fournir. Réserver plus de 2 kW par DZD signifie payer pour une capacité inutilisée. +!!! warning "Ne surcommandez pas l'alimentation" + Vous payez pour la puissance que vous réservez, que vous la consommiez ou non. Un DZD est une seule unité de rack de commutation, pas un châssis de calcul, il consomme donc bien moins que ce que sa position de rack pourrait fournir. Réserver plus de 2 kW par DZD signifie payer pour une capacité inutilisée. !!! note "Vérifiez votre propre matériel avant de commander" - Ce sont des chiffres indicatifs issus de nos propres déploiements. Votre consommation réelle dépend de la configuration de votre alimentation, du nombre de ports que vous allumez et des optiques que vous choisissez. Confirmez avec les spécifications d'alimentation dans la fiche technique du fabricant pour le matériel exact que vous achetez. + Ce sont des chiffres indicatifs issus de nos propres déploiements. Votre consommation réelle dépend de la configuration de votre alimentation, du nombre de ports que vous allumez et des optiques que vous choisissez. Vérifiez en vous référant aux spécifications d'alimentation dans la fiche technique du fabricant pour le matériel exact que vous achetez. - Ne réduisez pas non plus la commande au strict minimum. L'alimentation doit être disponible dans le rack, et ajouter une alimentation ultérieurement nécessite généralement une nouvelle commande auprès de l'installation, ce qui peut prendre des semaines. + Ne réduisez pas non plus la commande au strict minimum. L'alimentation doit être disponible dans le rack, et ajouter une alimentation ultérieurement signifie généralement une nouvelle commande auprès de l'installation, ce qui peut prendre des semaines. --- diff --git a/docs/contribute.it.md b/docs/contribute.it.md index fe929f4..58c3591 100644 --- a/docs/contribute.it.md +++ b/docs/contribute.it.md @@ -1,61 +1,61 @@ --- -description: Requisiti hardware, di banda e di connettività e architettura per contribuire capacità alla rete DoubleZero. +description: Requisiti hardware, di larghezza di banda e di connettività e architettura per contribuire capacità alla rete DoubleZero. --- # Requisiti e Architettura per i Contributori ## Riepilogo -Chiunque desideri monetizzare i propri cavi in fibra ottica e hardware di rete sottoutilizzati può contribuire alla rete DoubleZero. I contributori di rete devono fornire banda dedicata tra due punti, operare dispositivi compatibili con DoubleZero (DZD) a ciascuna estremità e una connessione alla rete internet pubblica a ciascuna estremità. I contributori di rete devono inoltre eseguire il software DoubleZero su ciascun DZD per fornire servizi come multicast, ricerca utenti e filtraggio perimetrale. +Chiunque desideri monetizzare i propri cavi in fibra ottica e hardware di rete sottoutilizzati può contribuire alla rete DoubleZero. I contributori di rete devono fornire larghezza di banda dedicata tra due punti, operare dispositivi compatibili con DoubleZero (DZD) a ciascuna estremità e una connessione alla rete internet pubblica a ciascuna estremità. I contributori di rete devono inoltre eseguire il software DoubleZero su ciascun DZD per fornire servizi come multicast, ricerca utenti e filtraggio perimetrale. -Lo smart contract di DoubleZero è il pilastro fondamentale per garantire che la rete mantenga collegamenti di alta qualità che possano essere misurati e integrati nella topologia, consentendo ai nostri controller di rete di sviluppare il percorso end-to-end più efficiente tra i diversi utenti e endpoint. Al momento dell'esecuzione dello smart contract e del deployment delle apparecchiature di rete e della banda, un'entità viene classificata come contributore di rete. Consultare [DoubleZero Economics](https://economics.doublezero.xyz/overview) per comprendere meglio gli aspetti economici della partecipazione a DoubleZero come contributore di rete. +Lo smart contract di DoubleZero è il fondamento per garantire che la rete mantenga collegamenti di alta qualità che possano essere misurati e integrati nella topologia, consentendo ai nostri controller di rete di sviluppare il percorso end-to-end più efficiente tra i diversi utenti e endpoint. Al momento dell'esecuzione dello smart contract e del deployment delle apparecchiature di rete e della larghezza di banda, un'entità viene classificata come contributore di rete. Consultare [DoubleZero Economics](https://economics.doublezero.xyz/overview) per comprendere meglio l'economia alla base della partecipazione a DoubleZero come contributore di rete. --- ## Requisiti per Diventare un Contributore della Rete DoubleZero -- Banda dedicata in grado di fornire connettività IPv4 e un MTU di 2048 byte tra due data center +- Larghezza di banda dedicata in grado di fornire connettività IPv4 e un MTU di 2048 byte tra due data center - Hardware DoubleZero Device (DZD) compatibile con il protocollo DoubleZero - Connettività a internet e ad altri contributori della rete DoubleZero - Installazione del software DoubleZero sul DZD ## Guida Rapida -Come contributore di rete, il modo più semplice per iniziare con DoubleZero è identificare la capacità nella propria rete che può essere dedicata a DoubleZero. Una volta identificata, i DZD devono essere distribuiti, facilitando la rete overlay DoubleZero che richiede solo raggiungibilità IPv4 e un MTU minimo di 2048 byte come dipendenze dalla rete del contributore. +Come contributore di rete, il modo più semplice per iniziare con DoubleZero è identificare la capacità nella propria rete che può essere dedicata a DoubleZero. Una volta identificata, i DZD devono essere installati, facilitando la rete overlay DoubleZero che richiede come dipendenze dalla rete del contributore solo raggiungibilità IPv4 e un MTU minimo di 2048 byte. -La Figura 1 illustra il modello più semplice per contribuire banda e servizi di invio ed elaborazione dei pacchetti. Un DZD viene distribuito in ciascun data center, interfacciandosi con la rete interna del contributore per fornire connettività WAN DoubleZero. Questo è completato da internet locale, tipicamente una soluzione di Accesso Internet Diretto (DIA), utilizzata come punto di accesso per gli utenti DoubleZero. Sebbene si preveda che il DIA sarà l'opzione preferita per facilitare l'accesso agli utenti di DoubleZero, sono possibili numerosi modelli di connettività, ad esempio cablaggio fisico ai server, estensione del fabric di rete, ecc. Ci riferiamo a queste opzioni come Choose Your Own Adventure (CYOA), fornendo al contributore la flessibilità di connettere utenti locali o remoti nel modo più adatto alle proprie politiche di rete interna. +La Figura 1 illustra il modello più semplice per contribuire larghezza di banda e servizi di invio e elaborazione pacchetti. Un DZD viene installato in ciascun data center, interfacciandosi con la rete interna del contributore per fornire connettività WAN DoubleZero. Questo è completato da internet locale, tipicamente una soluzione Direct Internet Access (DIA), utilizzata come punto di accesso per gli utenti DoubleZero. Sebbene si preveda che il DIA sarà l'opzione preferita per facilitare l'accesso agli utenti di DoubleZero, sono possibili numerosi modelli di connettività, ad es. cablaggio fisico ai server, estensione del fabric di rete, ecc. Ci riferiamo a queste opzioni come Choose Your Own Adventure (CYOA), offrendo al contributore la flessibilità di connettere utenti locali o remoti nel modo che meglio si adatta alle proprie politiche di rete interne. Come per qualsiasi rete, la raggiungibilità è una parte fondamentale dell'architettura poiché i contributori di rete non possono operare in isolamento. Pertanto, il DZD *deve* avere un collegamento a un DoubleZero Exchange (DZX) per creare una rete contigua tra i partecipanti.
![Image title](images/figure1.png){ width="800" } -
Figura 1: Contribuzione di Banda alla Rete DoubleZero tra 2 Data Center - Singolo Contributore
+
Figura 1: Contributo di Larghezza di Banda della Rete DoubleZero tra 2 Data Center - Singolo Contributore
-### Esempi di Contribuzione +### Esempi di Contributi -I modi in cui un contributore di rete può ampliare le proprie contribuzioni a DoubleZero sono molteplici, tra cui: +I modi in cui un contributore di rete può espandere i propri contributi a DoubleZero sono molteplici, tra cui: -- Migliorare le caratteristiche prestazionali delle contribuzioni esistenti: aumentare la banda, ridurre la latenza -- Aggiungere più collegamenti tra gli stessi data center +- Migliorare le caratteristiche prestazionali dei contributi esistenti: aumentare la larghezza di banda, ridurre la latenza +- Aggiungere collegamenti multipli tra gli stessi data center - Aggiungere un nuovo collegamento da un data center esistente a un nuovo data center - Aggiungere un nuovo collegamento indipendente tra due nuovi data center #### Esempio 1: Singolo Contributore, 3 Data Center, Due Collegamenti
![Image title](images/figure2.png){ width="800" } -
Figura 2: Contribuzione di Banda alla Rete DoubleZero tra 3 Data Center - Singolo Contributore
+
Figura 2: Contributo di Larghezza di Banda della Rete DoubleZero tra 3 Data Center - Singolo Contributore
-Un singolo DZD può supportare più collegamenti contribuiti a DoubleZero. La Figura 2 illustra una possibile topologia nel caso in cui un singolo data center, indicato come 1, termini la banda verso due diversi data center remoti 2 e 3. In questo scenario, ciascun data center contiene solo 1 DZD. Tutti i DZD utilizzano DIA per i punti di accesso utente come interfaccia CYOA. +Un singolo DZD può supportare più collegamenti contribuiti a DoubleZero. La Figura 2 illustra una potenziale topologia nel caso in cui un singolo data center, indicato come 1, termini la larghezza di banda verso due diversi data center remoti 2 e 3. In questo scenario, ciascun data center contiene solo 1 DZD. Tutti i DZD utilizzano DIA per i punti di accesso utente come interfaccia CYOA. #### Esempio 2: Singolo Contributore, 3 Data Center, Tre Collegamenti -La Figura 3 descrive la topologia DoubleZero quando un singolo contributore distribuisce tre collegamenti in una topologia a triangolo tra 3 data center. In uno scenario simile all'esempio 1, un singolo DZD viene distribuito nei data center 1, 2 e 3, ciascuno con supporto per 2 collegamenti di rete indipendenti. La topologia risultante è un triangolo o anello tra i data center. +La Figura 3 descrive la topologia DoubleZero quando un singolo contributore installa tre collegamenti in una topologia a triangolo tra 3 data center. In uno scenario simile all'esempio 1, un singolo DZD viene installato nei data center 1, 2 e 3, ciascuno che supporta 2 collegamenti di rete indipendenti. La topologia risultante è un triangolo o anello tra i data center.
![Image title](images/figure3.png){ width="800" } -
Figura 3: Contribuzione di Banda alla Rete DoubleZero tra 3 Data Center - Singolo Contributore
+
Figura 3: Contributo di Larghezza di Banda della Rete DoubleZero tra 3 Data Center - Singolo Contributore
### DoubleZero Exchange @@ -66,64 +66,64 @@ Nella Figura 4, il contributore di rete 1 opera nei data center 1, 2 e 3, mentre
![Image title](images/figure4.png){ width="1000" } -
Figura 4: Contribuzione di Banda alla Rete DoubleZero tra 2 Contributori di Banda di Rete
+
Figura 4: Contributo di Larghezza di Banda della Rete DoubleZero tra 2 Contributori di Larghezza di Banda di Rete
-### Opzioni di Contribuzione della Banda +### Opzioni di Contributo della Larghezza di Banda -DoubleZero richiede che un contributore di rete offra connettività integrata tramite un profilo garantito di banda, latenza e jitter tra i DZD in due data center terminali, espresso tramite uno smart contract. DoubleZero non impone come un contributore di rete implementi la propria contribuzione; tuttavia, nelle sezioni seguenti forniamo opzioni indicative da utilizzare a propria discrezione. +DoubleZero richiede che un contributore di rete offra connettività integrata tramite un profilo garantito di larghezza di banda, latenza e jitter tra i DZD in due data center di terminazione, espresso tramite uno smart contract. DoubleZero non impone come un contributore di rete implementi il proprio contributo, tuttavia, nelle sezioni seguenti forniamo opzioni indicative da utilizzare a propria esclusiva discrezione. -Aree importanti da considerare per un contributore di rete potrebbero essere: +Aspetti importanti da considerare per un contributore di rete potrebbero essere: -- Capacità di garantire le prestazioni di rete del servizio DoubleZero: banda, latenza e jitter +- Capacità di garantire le prestazioni di rete del servizio DoubleZero: larghezza di banda, latenza e jitter - Segregazione dai servizi di rete interni esistenti -- Conflitti di indirizzamento IPv4, specificamente con lo spazio di indirizzi dell'underlay del tunnel +- Conflitti di indirizzamento IPv4, in particolare con lo spazio di indirizzi dell'underlay del tunnel - Uptime e disponibilità - Considerazioni su CAPEX e OPEX -#### Banda Layer 1 +#### Larghezza di Banda Layer 1
![Image title](images/figure5.png){ width="800" } -
Figura 5: Servizi Ottici Layer 1
+
Figura 5: Servizi Ottici Layer 1
-La banda Layer 1, più formalmente descritta come servizi a lunghezza d'onda, può prevedere capacità dedicata fornita su un'infrastruttura ottica esistente, come DWDM, CWDM o tramite multiplexer ottici (MUX). Nella Figura 5, i DZD utilizzano un'ottica colorata collegata a un MUX L1, che inserisce la lunghezza d'onda del DZD su una fibra ottica spenta esistente. +La larghezza di banda Layer 1, più formalmente descritta come servizi a lunghezza d'onda, può prevedere capacità dedicata provisionata su un'infrastruttura ottica esistente, come DWDM, CWDM o tramite multiplexer ottici (MUX). Nella Figura 5, i DZD utilizzano un'ottica colorata cablata a un MUX L1, che intercala la lunghezza d'onda del DZD su una fibra ottica spenta esistente. -Questa soluzione offre numerosi vantaggi per i contributori di rete che operano già una rete core esistente. Le modifiche operative incrementali, così come i requisiti aggiuntivi di CAPEX e OPEX, sono modesti. Questa opzione è particolarmente robusta nell'offrire segregazione dai servizi di rete del contributore. +Questa soluzione offre numerosi vantaggi per i contributori di rete che già operano una rete core esistente. Le modifiche operative incrementali, così come i requisiti aggiuntivi di CAPEX e OPEX, sono modesti. Questa opzione è particolarmente robusta nell'offrire segregazione dai servizi di rete del contributore. -#### Banda a Commutazione di Pacchetto +#### Larghezza di Banda a Commutazione di Pacchetto -Le reti a commutazione di pacchetto possono essere considerate una tipica rete aziendale, che esegue protocolli standard di routing e switching a supporto delle applicazioni aziendali. Esistono numerose tecnologie di rete che garantiscono la connettività, ad esempio estensioni layer 2 (L2) tramite tag VLAN. +Le reti a commutazione di pacchetto possono essere considerate una tipica rete aziendale, che esegue protocolli standard di routing e switching a supporto delle applicazioni aziendali. Esistono numerose tecnologie di rete che realizzano la connettività, ad esempio estensioni layer 2 (L2) tramite tag VLAN. ##### Estensione L2
![Image title](images/figure6.png){ width="800" } -
Figura 6: Reti a Commutazione di Pacchetto - Estensione L2
+
Figura 6: Reti a Commutazione di Pacchetto - Estensione L2
-Un'estensione L2 come mostrata nella Figura 6 può essere facilitata tramite il tagging VLAN. La porta di un DZD può essere collegata allo switch di rete interno del contributore, con la porta dello switch configurata come porta di accesso, ad esempio nella VLAN 10. Attraverso il tagging 802.1q, questa VLAN può essere trasportata su più hop di switch nella rete del contributore, terminando allo switch che si interfaccia con il DZD remoto. +Un'estensione L2 come mostrato nella Figura 6 può essere facilitata tramite tagging VLAN. La porta di un DZD può essere cablata a uno switch della rete interna del contributore, con la porta dello switch configurata come access port, ad esempio nella VLAN 10. Tramite tagging 802.1q, questa VLAN può essere trasportata su più hop di switch nella rete del contributore, terminando allo switch che si interfaccia con il DZD remoto. -Questa soluzione beneficia di un ampio supporto e di una relativa facilità di implementazione, creando al contempo segmentazione tra DoubleZero e i servizi layer 3 interni. La banda può essere controllata in base alla velocità dell'interfaccia dello switch o router interno del contributore. È necessario prestare particolare attenzione alle prestazioni sulla rete L2 interna condivisa attraverso tecnologie come Quality of Service (QoS) o altre politiche di gestione del traffico. Tuttavia, gli investimenti aggiuntivi in CAPEX e OPEX dovrebbero essere modesti se è disponibile capacità esistente all'interno della rete core del contributore. +Questa soluzione beneficia dell'essere ampiamente supportata e relativamente facile da implementare, creando al contempo segmentazione tra DoubleZero e i servizi layer 3 interni. La larghezza di banda può essere controllata in base alla velocità dell'interfaccia dello switch o router interno del contributore. È necessario prestare particolare attenzione alle prestazioni sulla rete L2 interna condivisa attraverso tecnologie come Quality of Service (QoS) o altre politiche di gestione del traffico. Tuttavia, gli investimenti aggiuntivi in CAPEX e OPEX dovrebbero essere modesti se è disponibile capacità esistente all'interno della rete core del contributore. -#### Banda Dedicata di Terze Parti +#### Larghezza di Banda Dedicata di Terze Parti
![Image title](images/figure7.png){ width="800" } -
Figura 7: Banda Dedicata di Terze Parti
+
Figura 7: Larghezza di Banda Dedicata di Terze Parti
-Sebbene il riutilizzo della capacità disponibile sarà attraente per molti contributori di rete, è anche possibile dedicare banda di nuova acquisizione a DoubleZero. In tale scenario, il DZD si collegherebbe direttamente al carrier di terze parti senza che alcun dispositivo interno del contributore si trovi in linea (Figura 7). +Sebbene il riutilizzo della capacità disponibile sarà interessante per molti contributori di rete, è anche possibile dedicare larghezza di banda acquisita ex novo a DoubleZero. In tale scenario, il DZD si connetterebbe direttamente al carrier di terze parti senza alcun dispositivo interno del contributore posizionato in linea (Figura 7). -Questa opzione è attraente in quanto garantisce banda dedicata per DoubleZero, è semplice dal punto di vista operativo e assicura una segmentazione completa da qualsiasi altro servizio di rete. Questa opzione comporterà probabilmente il maggiore incremento di OPEX e richiede nuovi contratti di servizio con carrier di terze parti. +Questa opzione è interessante in quanto garantisce larghezza di banda dedicata per DoubleZero, è operativamente semplice e assicura una completa segmentazione da qualsiasi altro servizio di rete. Questa opzione comporterà probabilmente il maggiore incremento di OPEX e richiede nuovi contratti di servizio con carrier di terze parti. --- ## Requisiti Hardware -### Contribuzione di Banda a 100Gbps +### Contributo di Larghezza di Banda a 100Gbps -Si noti che le quantità riportate di seguito riflettono l'attrezzatura necessaria in due data center, ovvero l'hardware totale richiesto per distribuire 1 cavo in fibra ottica per la contribuzione di banda. +Si noti che le quantità indicate di seguito riflettono le apparecchiature necessarie in due data center, ovvero l'hardware totale necessario per installare 1 cavo in fibra ottica per il contributo di larghezza di banda. -??? warning "*Tutti gli FPGA sono soggetti a test finali. Le contribuzioni a 10G possono essere supportate utilizzando switch Arista 7130LBR con doppi FPGA Virtex® UltraScale+™ integrati (per qualsiasi domanda, DoubleZero Foundation / Malbec Labs sono lieti di fornire ulteriori informazioni)." +??? warning "*Tutti gli FPGA sono soggetti a test finali. I contributi a 10G possono essere supportati utilizzando switch Arista 7130LBR con doppi FPGA Virtex® UltraScale+™ integrati (per qualsiasi domanda, DoubleZero Foundation / Malbec Labs sono lieti di fornire maggiori informazioni)." #### Requisiti di Funzione e Porte @@ -131,30 +131,30 @@ Si noti che le quantità riportate di seguito riflettono l'attrezzatura necessar |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Private Bandwidth | 100G | Sì | 1 | | | Direct Internet Access (DIA) | 10G | Sì | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato quando più di 3 provider operano nella stessa area metropolitana; prima di ciò, è possibile utilizzare cross-connect o altri accordi di peering per interconnettersi ad altri provider. | +| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato quando più di 3 provider operano nella stessa area metropolitana; prima di ciò, è possibile utilizzare cross-connect o altri accordi di peering per l'interconnessione con altri provider. | | Management | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | | Console | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | #### Hardware di Rete DZD -| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +| Produttore | Modello | Codice Articolo | Requisito DZ | QTÀ | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | Sì | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Potrebbero essere possibili alternative in caso di tempi di consegna difficili. | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Alternative possibili in caso di tempi di consegna impegnativi. | --- #### Ottiche - 100G -| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +| Produttore | Modello | Codice Articolo | Requisito DZ | QTÀ | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | Cablaggio e scelta delle ottiche a discrezione del contributore. 100G richiesti per connettere gli FPGA. | +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 16 | Cablaggio e scelta delle ottiche a discrezione del contributore. 100G necessari per connettere gli FPGA. | --- #### Ottiche - 10G -| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +| Produttore | Modello | Codice Articolo | Requisito DZ | QTÀ | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| | Arista | 10GBASE-LR | SFP-10G-LR | No | 2 | Cablaggio e scelta delle ottiche a discrezione del contributore. | | Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 2 | Cablaggio e scelta delle ottiche a discrezione del contributore. | @@ -163,15 +163,15 @@ Si noti che le quantità riportate di seguito riflettono l'attrezzatura necessar #### Indirizzamento IP -| Indirizzamento IP | Dimensione Minima Subnet | Requisito DZ | Nota | +| Indirizzamento IP | Dimensione Minima Sottorete | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| | Public IPv4 | /29 | Sì (per DZD edge/ibridi) | Deve essere instradabile tramite DIA. Potremmo eliminare questa necessità nel tempo. | -Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Eventuali requisiti di indirizzamento point-to-point, ad esempio sulle interfacce DIA, devono essere gestiti tramite un pool di indirizzi diverso. +Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Qualsiasi requisito per indirizzamento punto-punto, ad es. sulle interfacce DIA, deve essere gestito tramite un pool di indirizzi diverso. -### Contribuzione di Banda a 10Gbps +### Contributo di Larghezza di Banda a 10Gbps -Si noti che le quantità riflettono l'attrezzatura per due data center, ovvero l'hardware totale richiesto per distribuire 1 contribuzione di banda. +Si noti che le quantità riflettono le apparecchiature di due data center, ovvero l'hardware totale necessario per installare 1 contributo di larghezza di banda. #### Requisiti di Funzione e Porte @@ -179,7 +179,7 @@ Si noti che le quantità riflettono l'attrezzatura per due data center, ovvero l |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Private Bandwidth | 10G | Sì | 1 | | | Direct Internet Access (DIA) | 10G | Sì | 2 | | -| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato quando più di 3 provider operano nella stessa area metropolitana; prima di ciò, è possibile utilizzare cross-connect o altri accordi di peering per interconnettersi ad altri provider. | +| DoubleZero eXchange (DZX) | 100G | Sì* | 1 | Deve essere supportato quando più di 3 provider operano nella stessa area metropolitana; prima di ciò, è possibile utilizzare cross-connect o altri accordi di peering per l'interconnessione con altri provider. | | Management | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | | Console | | No | 1 | Determinato dalle politiche di gestione interne del contributore. | @@ -187,24 +187,24 @@ Si noti che le quantità riflettono l'attrezzatura per due data center, ovvero l #### Hardware -| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +| Produttore | Modello | Codice Articolo | Requisito DZ | QTÀ | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474* | Sì | 4 | | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Potrebbero essere possibili alternative in caso di tempi di consegna difficili. | +| Arista | 7280CR3A | DCS-7280CR3A-32S | Sì | 2 | Alternative possibili in caso di tempi di consegna impegnativi. | --- #### Ottiche - 100G -| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +| Produttore | Modello | Codice Articolo | Requisito DZ | QTÀ | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | Cablaggio e scelta delle ottiche a discrezione del contributore. 100G richiesti per connettere gli FPGA. | +| Arista | 100GBASE-LR | QSFP-100G-LR | No | 14 | Cablaggio e scelta delle ottiche a discrezione del contributore. 100G necessari per connettere gli FPGA. | --- #### Ottiche - 10G -| Produttore | Modello | Codice Prodotto | Requisito DZ | QTÀ | Nota | +| Produttore | Modello | Codice Articolo | Requisito DZ | QTÀ | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| | Arista | 10GBASE-LR | SFP-10G-LR | No | 4 | Cablaggio e scelta delle ottiche a discrezione del contributore. | Finisar | DynamiX QSA™ | MAM1Q00A-QSA | No | 4 | Cablaggio e scelta delle ottiche a discrezione del contributore. | @@ -212,26 +212,26 @@ Si noti che le quantità riflettono l'attrezzatura per due data center, ovvero l #### Indirizzamento IP -| Indirizzamento IP | Dimensione Minima Subnet | Requisito DZ | Nota | +| Indirizzamento IP | Dimensione Minima Sottorete | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| | Public IPv4 | /29 | Sì (per DZD edge/ibridi) | Deve essere instradabile tramite DIA. Potremmo eliminare questa necessità nel tempo. | -Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Eventuali requisiti di indirizzamento point-to-point, ad esempio sulle interfacce DIA, devono essere gestiti tramite un pool di indirizzi diverso. +Assicurarsi che l'intero pool /29 sia disponibile per il protocollo DZ. Qualsiasi requisito per indirizzamento punto-punto, ad es. sulle interfacce DIA, deve essere gestito tramite un pool di indirizzi diverso. ### Requisiti del Data Center #### Requisiti di Rack e Alimentazione -Le cifre seguenti sono **per DZD**, quindi per data center. Una contribuzione di banda a 100G o 10G posiziona un DZD a ciascuna estremità del collegamento, quindi pianificare il tutto due volte. +Le cifre seguenti sono **per DZD**, quindi per data center. Un contributo di larghezza di banda a 100G o 10G posiziona un DZD a ciascuna estremità del collegamento, quindi pianificare il tutto due volte. ##### Spazio rack | Elemento | Unità rack | Necessario | |------|-----------|--------| | Switch DZD (Arista 7280CR3A-32S o 7130LBR) | 1U | Ora | -| Appliance di filtraggio perimetrale | 1U | In seguito, solo sui dispositivi edge e ibridi | +| Appliance di filtraggio perimetrale | 1U | In seguito, solo su dispositivi edge e ibridi | -**Riservare 2U per DZD.** Un'unità è in uso oggi. Mantenere la seconda libera in modo che l'appliance di filtraggio perimetrale possa essere posizionata accanto allo switch senza spostamenti nel rack. Lasciare spazio per il flusso d'aria e la gestione dei cavi come richiesto dalla propria struttura. +**Riservare 2U per DZD.** Un'unità è in uso oggi. Mantenere la seconda libera in modo che l'appliance di filtraggio perimetrale possa essere posizionata accanto allo switch senza spostamenti nel rack. Lasciare spazio per il flusso d'aria e la gestione dei cavi come richiesto dalla vostra struttura. ##### Alimentazione @@ -240,20 +240,20 @@ Le cifre seguenti sono **per DZD**, quindi per data center. Una contribuzione di | Arista 7280CR3A-32S | ~300 W | | Ottiche, per 100G QSFP | ~5 W | -**Ordinare 2 kW per DZD, suddivisi su due alimentazioni indipendenti.** Dimensionare ciascuna alimentazione in modo da poter sostenere l'intero carico autonomamente. Lo switch dispone di alimentatori ridondanti e, dopo un guasto di una linea, uno di essi potrebbe essere l'unico rimasto. +**Ordinare 2 kW per DZD, suddivisi su due linee di alimentazione indipendenti.** Dimensionare ciascuna linea per sostenere l'intero carico da sola. Lo switch dispone di alimentatori ridondanti e, dopo un guasto a una linea, uno di essi potrebbe essere l'unico rimasto. -2 kW è una misura confortevole piuttosto che risicata. Un DZD con solo switch, che è ciò che esegue quasi ogni deployment oggi, consuma ben meno di 500 W con tutte le ottiche attive. Il resto dei 2 kW è riservato all'appliance di filtraggio perimetrale, che contiene gli FPGA e viene installata successivamente. +2 kW è una stima confortevole piuttosto che tirata. Un DZD con solo switch, che è ciò che viene installato nella quasi totalità dei deployment attuali, consuma ben al di sotto di 500 W con tutte le ottiche accese. Il resto dei 2 kW è riservato per l'appliance di filtraggio perimetrale, che contiene gli FPGA e viene installata successivamente. -!!! warning "Non sovradimensionare l'alimentazione" - Si paga per la potenza riservata, indipendentemente dal fatto che venga consumata o meno. Un DZD è una singola unità rack di switching, non un chassis di calcolo, quindi consuma molto meno di quanto la sua posizione nel rack potrebbe fornire. Riservare più di 2 kW per DZD significa pagare per capacità inutilizzata. +!!! warning "Non sovradimensionare l'ordine di alimentazione" + Si paga per la potenza riservata, indipendentemente dal fatto che venga effettivamente consumata. Un DZD è una singola unità rack di switching, non un chassis di calcolo, quindi consuma molto meno di quanto la sua posizione nel rack potrebbe fornire. Riservare più di 2 kW per DZD significa pagare per capacità inutilizzata. !!! note "Verificare il proprio hardware prima di ordinare" - Queste sono cifre indicative dai nostri deployment. Il consumo reale dipende dalla configurazione degli alimentatori, dal numero di porte attivate e dalle ottiche scelte. Verificare rispetto alle specifiche degli alimentatori nel datasheet del produttore per l'hardware esatto acquistato. + Queste sono cifre indicative dai nostri deployment. Il consumo reale dipende dalla configurazione degli alimentatori, da quante porte vengono attivate e da quali ottiche si scelgono. Verificare rispetto alle specifiche degli alimentatori nel datasheet del produttore per l'hardware esatto che si acquista. - Non ridurre l'ordine al minimo indispensabile. L'alimentazione deve essere disponibile nel rack, e aggiungere una linea successivamente di solito comporta un nuovo ordine presso la struttura, che può richiedere settimane. + Non ridurre l'ordine al minimo indispensabile. L'alimentazione deve essere disponibile nel rack, e aggiungere una linea successivamente di solito comporta un nuovo ordine con la struttura, il che può richiedere settimane. --- -## Prossimi Passi +## Passaggi Successivi -Pronti a effettuare il provisioning del vostro primo DZD? Proseguire alla [Guida al Provisioning del Dispositivo](contribute-provisioning.md). \ No newline at end of file +Pronti per il provisioning del vostro primo DZD? Proseguite con la [Guida al Provisioning del Dispositivo](contribute-provisioning.md). \ No newline at end of file diff --git a/docs/contribute.ja.md b/docs/contribute.ja.md index 058e5a8..5fe0b13 100644 --- a/docs/contribute.ja.md +++ b/docs/contribute.ja.md @@ -6,114 +6,114 @@ description: DoubleZeroネットワークへの容量提供に必要なハード ## 概要 -未使用の光ファイバーケーブルやネットワークハードウェアを収益化したい方は、誰でもDoubleZeroネットワークに貢献することができます。ネットワークコントリビューターは、2つの拠点間で専用帯域幅を提供し、各端にDoubleZero対応デバイス（DZD）を運用し、各端でパブリックインターネットへの接続を確保する必要があります。また、ネットワークコントリビューターは、マルチキャスト、ユーザー検索、エッジフィルタリングなどのサービスを提供するために、各DZDでDoubleZeroソフトウェアを実行する必要があります。 +未活用の光ファイバーケーブルやネットワークハードウェアを収益化したい方は、誰でもDoubleZeroネットワークに貢献できます。ネットワークコントリビューターは、2つの拠点間の専用帯域幅を提供し、各端でDoubleZero互換デバイス（DZD）を運用し、各端でパブリックインターネットへの接続を確保する必要があります。また、ネットワークコントリビューターは、マルチキャスト、ユーザー検索、エッジフィルタリングなどのサービスを提供するために、各DZDでDoubleZeroソフトウェアを実行する必要があります。 -DoubleZeroスマートコントラクトは、ネットワークが高品質なリンクを維持し、それらを測定してトポロジに統合できることを保証するための基盤です。これにより、ネットワークコントローラーは異なるユーザーやエンドポイント間の最も効率的なエンドツーエンドパスを構築できます。スマートコントラクトの実行およびネットワーク機器と帯域幅の展開が完了すると、そのエンティティはネットワークコントリビューターとして分類されます。DoubleZeroにネットワークコントリビューターとして参加する際の経済的仕組みについては、[DoubleZero Economics](https://economics.doublezero.xyz/overview)をご覧ください。 +DoubleZeroスマートコントラクトは、ネットワークが高品質なリンクを維持し、それを測定してトポロジーに統合できるようにするための基盤です。これにより、ネットワークコントローラーはさまざまなユーザーやエンドポイント間で最も効率的なエンドツーエンドパスを構築できます。スマートコントラクトの実行およびネットワーク機器と帯域幅の展開が完了すると、そのエンティティはネットワークコントリビューターとして分類されます。ネットワークコントリビューターとしてDoubleZeroに参加する際の経済モデルの詳細については、[DoubleZero Economics](https://economics.doublezero.xyz/overview)をご覧ください。 --- -## DoubleZeroネットワークコントリビューターになるための要件 +## DoubleZeroネットワークコントリビューターの要件 - 2つのデータセンター間でIPv4接続と2048バイトのMTUを提供できる専用帯域幅 -- DoubleZeroプロトコルに対応したDoubleZero Device（DZD）ハードウェア -- インターネットおよび他のDoubleZeroネットワークコントリビューターへの接続性 +- DoubleZeroプロトコルと互換性のあるDoubleZero Device（DZD）ハードウェア +- インターネットおよび他のDoubleZeroネットワークコントリビューターへの接続 - DZDへのDoubleZeroソフトウェアのインストール ## クイックスタートガイド -ネットワークコントリビューターとして、DoubleZeroを始める最も簡単な方法は、DoubleZeroに専用で提供できるネットワーク内の空き容量を特定することです。特定後、DZDを展開する必要があります。DZDはDoubleZeroオーバーレイネットワークを構築し、コントリビューターのネットワークからの依存要件としてIPv4到達性と最小2048バイトのMTUのみを必要とします。 +ネットワークコントリビューターとしてDoubleZeroを開始する最も簡単な方法は、DoubleZero専用にできるネットワーク内の容量を特定することです。特定後、DZDを展開する必要があります。DZDはDoubleZeroオーバーレイネットワークを構築し、コントリビューターのネットワークからの依存要件はIPv4到達性と最小2048バイトのMTUのみです。 -図1は、帯域幅の提供とパケット送受信・処理サービスの最もシンプルなモデルを示しています。各データセンターにDZDが展開され、ネットワークコントリビューターの内部ネットワークとインターフェースしてDoubleZero WAN接続を提供します。これに加えて、DoubleZeroユーザーのオンランプとして使用されるローカルインターネット（通常はDirect Internet Access（DIA）ソリューション）が補完的に提供されます。DIAがDoubleZeroユーザーへのアクセス提供の優先オプションとなることが予想されますが、サーバーへの物理ケーブリング、ネットワークファブリック拡張など、多数の接続モデルが可能です。これらのオプションをChoose Your Own Adventure（CYOA）と呼び、コントリビューターが内部ネットワークポリシーに最適な方法でローカルまたはリモートユーザーを接続する柔軟性を提供します。 +図1は、帯域幅およびパケット送受信・処理サービスを提供する最もシンプルなモデルを示しています。各データセンターにDZDが展開され、DoubleZero WANの接続性を提供するためにネットワークコントリビューターの内部ネットワークとインターフェースします。これに加えて、DoubleZeroユーザーのオンランプとして使用されるローカルインターネット（通常はDirect Internet Access（DIA）ソリューション）が補完します。DIAがDoubleZeroユーザーへのアクセスを提供するための推奨オプションになると想定されていますが、物理ケーブルによるサーバー接続、ネットワークファブリック拡張など、多数の接続モデルが可能です。これらのオプションをChoose Your Own Adventure（CYOA）と呼び、コントリビューターが自社の内部ネットワークポリシーに最も適した方法でローカルまたはリモートユーザーを接続できる柔軟性を提供します。 -あらゆるネットワークと同様に、到達性はアーキテクチャの基本的な要素であり、ネットワークコントリビューターは孤立して存在することはできません。そのため、DZDは参加者間の連続したネットワークを構築するために、DoubleZero Exchange（DZX）へのリンクを*必ず*持つ必要があります。 +あらゆるネットワークと同様に、到達性はアーキテクチャの基本的な要素であり、ネットワークコントリビューターは孤立して存在することはできません。そのため、DZDは参加者間の連続したネットワークを構築するために、DoubleZero Exchange（DZX）へのリンクを*必ず*持たなければなりません。
![Image title](images/figure1.png){ width="800" } -
図1: 2つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
+
図1：2つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
### 提供の例 -ネットワークコントリビューターがDoubleZeroへの貢献を拡大する方法は多数あります。以下はその例です： +ネットワークコントリビューターがDoubleZeroへの貢献を拡大する方法は多岐にわたります： -- 既存の貢献のパフォーマンス特性を改善する：帯域幅の増加、レイテンシの削減 +- 既存の提供のパフォーマンス特性を改善する：帯域幅の増加、レイテンシの削減 - 同じデータセンター間に複数のリンクを追加する - 既存のデータセンターから新しいデータセンターへの新しいリンクを追加する - 2つの新しいデータセンター間に新しい独立したリンクを追加する -#### 例1: 単一コントリビューター、3つのデータセンター、2つのリンク +#### 例1：単一コントリビューター、3つのデータセンター、2つのリンク
![Image title](images/figure2.png){ width="800" } -
図2: 3つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
+
図2：3つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
-単一のDZDはDoubleZeroに提供される複数のリンクをサポートできます。図2は、データセンター1として示される単一のデータセンターが、2つの異なるリモートデータセンター2および3への帯域幅を終端する場合の潜在的なトポロジを示しています。このシナリオでは、各データセンターにDZDが1台のみ含まれます。すべてのDZDは、CYOAインターフェースとしてDIAをユーザーオンランプに使用しています。 +単一のDZDは、DoubleZeroに提供される複数のリンクをサポートできます。図2は、データセンター1として示される単一のデータセンターが、2つの異なるリモートデータセンター2および3への帯域幅を終端する場合の潜在的なトポロジーを示しています。このシナリオでは、各データセンターにDZDが1台のみ含まれています。すべてのDZDは、CYOAインターフェースとしてDIAをユーザーオンランプに使用しています。 -#### 例2: 単一コントリビューター、3つのデータセンター、3つのリンク +#### 例2：単一コントリビューター、3つのデータセンター、3つのリンク -図3は、単一のコントリビューターが3つのデータセンター間にトライアングルトポロジで3つのリンクを展開した場合のDoubleZeroトポロジを示しています。例1と同様のシナリオで、データセンター1、2、3にそれぞれ1台のDZDが展開され、各DZDが2つの独立したネットワークリンクをサポートします。結果として得られるトポロジは、データセンター間のトライアングルまたはリング型となります。 +図3は、単一のコントリビューターが3つのデータセンター間にトライアングルトポロジーで3つのリンクを展開した場合のDoubleZeroトポロジーを示しています。例1と同様のシナリオで、データセンター1、2、3にそれぞれ1台のDZDが展開され、各DZDは2つの独立したネットワークリンクをサポートします。結果として得られるトポロジーは、データセンター間のトライアングルまたはリングになります。
![Image title](images/figure3.png){ width="800" } -
図3: 3つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
+
図3：3つのデータセンター間のDoubleZeroネットワーク帯域幅提供 - 単一コントリビューター
### DoubleZero Exchange -連続したネットワークの構築は、DoubleZeroアーキテクチャの基本的な構成要素です。コントリビューターは、ニューヨーク（NYC）、ロンドン（LON）、東京（TYO）などの都市を単位とした大都市圏内のDoubleZero Exchange（DZX）を介してインターフェースします。DZXはインターネットエクスチェンジに類似したネットワークファブリックであり、ピアリングとルート交換を可能にします。 +連続したネットワークの構築は、DoubleZeroアーキテクチャの基本的な構成要素です。コントリビューターは、ニューヨーク（NYC）、ロンドン（LON）、東京（TYO）などの都市である大都市圏内のDoubleZero Exchange（DZX）を介してインターフェースします。DZXはインターネットエクスチェンジに類似したネットワークファブリックであり、ピアリングと経路交換を可能にします。 -図4では、ネットワークコントリビューター1がデータセンター1、2、3で運用し、ネットワークコントリビューター2がデータセンター2、4、5で運用しています。データセンター2で相互接続することにより、DoubleZeroネットワークのリーチが5つの連続したデータセンターに拡大されます。 +図4では、ネットワークコントリビューター1がデータセンター1、2、3で運用し、ネットワークコントリビューター2がデータセンター2、4、5で運用しています。データセンター2で相互接続することにより、DoubleZeroネットワークの到達範囲は5つの連続したデータセンターに拡大します。
![Image title](images/figure4.png){ width="1000" } -
図4: 2つのネットワーク帯域幅コントリビューター間のDoubleZeroネットワーク帯域幅提供
+
図4：2つのネットワーク帯域幅コントリビューター間のDoubleZeroネットワーク帯域幅提供
### 帯域幅提供オプション -DoubleZeroでは、ネットワークコントリビューターが2つの終端データセンターのDZD間で保証された帯域幅、レイテンシ、ジッタープロファイルを通じた統合接続をスマートコントラクトで提供する必要があります。DoubleZeroはネットワークコントリビューターが貢献をどのように実装するかを強制しませんが、以下のセクションではコントリビューターの裁量で使用できる参考オプションを提供します。 +DoubleZeroでは、ネットワークコントリビューターが2つの終端データセンターのDZD間で、スマートコントラクトを通じて保証された帯域幅、レイテンシ、ジッタープロファイルによる統合接続を提供する必要があります。DoubleZeroはコントリビューターが提供をどのように実装するかを規定しませんが、以下のセクションでコントリビューターの裁量で使用できる参考オプションを提供します。 -ネットワークコントリビューターが考慮すべき重要な領域： +ネットワークコントリビューターが考慮すべき重要な項目は以下の通りです： -- DoubleZeroサービスのネットワークパフォーマンス保証能力：帯域幅、レイテンシ、ジッター +- DoubleZeroサービスのネットワークパフォーマンスを保証する能力：帯域幅、レイテンシ、ジッター - 既存の内部ネットワークサービスからの分離 -- IPv4アドレスの競合（特にトンネルアンダーレイアドレス空間との競合） +- IPv4アドレスの競合、特にトンネルアンダーレイアドレス空間との競合 - アップタイムと可用性 -- CAPEXとOPEXの考慮事項 +- CAPEXおよびOPEXの考慮事項 #### レイヤー1帯域幅
![Image title](images/figure5.png){ width="800" } -
図5: レイヤー1光サービス
+
図5：レイヤー1光サービス
-レイヤー1帯域幅（より正式には波長サービスと呼ばれる）は、DWDM、CWDMなどの既存の光インフラストラクチャ上、または光マルチプレクサ（MUX）を介して専用容量をプロビジョニングすることが可能です。図5では、DZDがカラードオプティックを使用し、L1 MUXにケーブル接続されており、既存のダークファイバー上にDZDの波長をインターリーブします。 +レイヤー1帯域幅（より正式には波長サービスと呼ばれる）は、DWDM、CWDMまたは光マルチプレクサ（MUX）などの既存の光インフラストラクチャ上に専用容量をプロビジョニングすることで実現できます。図5では、DZDはL1 MUXにケーブル接続されたカラーオプティクスを使用し、MUXがDZDの波長を既存のダークファイバーにインターリーブします。 -このソリューションは、既存のコアネットワークを運用しているネットワークコントリビューターにとって多くの利点があります。段階的な運用変更、追加のCAPEXおよびOPEX要件は控えめです。このオプションは、ネットワークコントリビューターのネットワークサービスからの分離を提供する点で特に堅牢です。 +このソリューションには、既存のコアネットワークを運用するネットワークコントリビューターにとって多くの利点があります。段階的な運用変更、および追加のCAPEXとOPEX要件は控えめです。このオプションは、ネットワークコントリビューターのネットワークサービスからの分離を提供する点で特に堅牢です。 -#### パケットスイッチ帯域幅 +#### パケットスイッチング帯域幅 -パケットスイッチネットワークは、標準的なルーティングおよびスイッチングプロトコルを実行してビジネスアプリケーションをサポートする一般的なエンタープライズネットワークと見なすことができます。接続を実現するネットワーク技術は多数あり、例えばVLANタグを使用したレイヤー2（L2）拡張などがあります。 +パケットスイッチングネットワークは、ビジネスアプリケーションをサポートする標準的なルーティングおよびスイッチングプロトコルを実行する、一般的なエンタープライズネットワークと見なすことができます。接続を実現するネットワーキング技術は多数あり、例えばVLANタグを使用したレイヤー2（L2）拡張などがあります。 ##### L2拡張
![Image title](images/figure6.png){ width="800" } -
図6: パケットスイッチネットワーク - L2拡張
+
図6：パケットスイッチングネットワーク - L2拡張
-図6に示すようなL2拡張は、VLANタグ付けによって実現できます。DZDのポートをコントリビューターの内部ネットワークスイッチにケーブル接続し、スイッチポートを例えばVLAN 10のアクセスポートとして設定します。802.1qタグ付けにより、このVLANはコントリビューターのネットワーク上の複数のスイッチホップを経由して転送され、リモートDZDとインターフェースするスイッチで終端されます。 +図6に示すL2拡張は、VLANタグ付けによって実現できます。DZDのポートをコントリビューターの内部ネットワークスイッチにケーブル接続し、スイッチポートを例えばVLAN 10のアクセスポートとして設定できます。802.1qタグ付けにより、このVLANはコントリビューターのネットワーク上の複数のスイッチホップを介して転送され、リモートDZDとインターフェースするスイッチで終端されます。 -このソリューションは、広くサポートされており比較的実装が容易であるという利点があり、DoubleZeroと内部レイヤー3サービス間のセグメンテーションを実現します。帯域幅は、コントリビューターの内部スイッチまたはルーターのインターフェース速度に基づいて制御できます。Quality of Service（QoS）やその他のトラフィック管理ポリシーなどの技術を通じて、共有内部L2ネットワーク全体のパフォーマンスに十分な注意を払う必要があります。ただし、コントリビューターのコアネットワーク内に既存の容量がある場合、追加のCAPEXおよびOPEX投資は控えめで済むはずです。 +このソリューションは、広くサポートされており、比較的簡単に実装でき、DoubleZeroと内部レイヤー3サービス間のセグメンテーションを作成できるという利点があります。帯域幅は、コントリビューターの内部スイッチまたはルーターのインターフェース速度に基づいて制御できます。Quality of Service（QoS）やその他のトラフィック管理ポリシーなどの技術を通じて、共有内部L2ネットワーク全体のパフォーマンスに十分な注意を払う必要があります。ただし、コントリビューターのコアネットワーク内に既存の容量がある場合、追加のCAPEXおよびOPEX投資は控えめであるはずです。 #### 専用サードパーティ帯域幅
![Image title](images/figure7.png){ width="800" } -
図7: 専用サードパーティ帯域幅
+
図7：専用サードパーティ帯域幅
-利用可能な容量の再利用は多くのネットワークコントリビューターにとって魅力的ですが、新たに取得した帯域幅をDoubleZeroに専用で提供することも可能です。そのようなシナリオでは、DZDはコントリビューターの内部デバイスを経由せずに、サードパーティキャリアに直接接続します（図7）。 +既存の容量を再利用することは多くのネットワークコントリビューターにとって魅力的ですが、新たに取得した帯域幅をDoubleZero専用にすることも可能です。そのようなシナリオでは、DZDはコントリビューターの内部デバイスを介さずにサードパーティキャリアに直接接続されます（図7）。 -このオプションは、DoubleZero専用の帯域幅を確保でき、運用がシンプルで、他のネットワークサービスからの完全な分離を保証するため魅力的です。このオプションはOPEXの増加が最も大きくなる可能性が高く、サードパーティキャリアとの新しいサービス契約が必要になります。 +このオプションは、DoubleZero専用の帯域幅を確保でき、運用がシンプルで、他のネットワークサービスからの完全な分離が保証されるため魅力的です。このオプションはOPEXの増加が最も大きくなる可能性があり、サードパーティキャリアとの新しいサービス契約が必要です。 --- @@ -121,9 +121,9 @@ DoubleZeroでは、ネットワークコントリビューターが2つの終端 ### 100Gbps帯域幅提供 -以下の数量は2つのデータセンターに必要な機器を反映しています。つまり、帯域幅提供用の光ファイバーケーブル1本を展開するために必要なハードウェアの合計です。 +以下の数量は2つのデータセンターで必要な機器を反映しています。つまり、帯域幅提供のために1本の光ファイバーケーブルを展開するために必要なハードウェアの合計です。 -??? warning "*すべてのFPGAは最終テストの対象です。10G提供は、デュアルVirtex® UltraScale+™ FPGAを内蔵したArista 7130LBRスイッチを使用してサポートされる場合があります（ご質問がある場合は、DoubleZero Foundation / Malbec Labsが詳細情報を提供いたします）。*" +??? warning "*すべてのFPGAは最終テストの対象です。10G提供は、デュアルVirtex® UltraScale+™ FPGA内蔵のArista 7130LBRスイッチを使用してサポートされる可能性があります（ご不明な点がございましたら、DoubleZero Foundation / Malbec Labsが詳細をご提供いたします）。*" #### 機能とポート要件 @@ -131,16 +131,16 @@ DoubleZeroでは、ネットワークコントリビューターが2つの終端 |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | プライベート帯域幅 | 100G | はい | 1 | | | Direct Internet Access (DIA) | 10G | はい | 2 | | -| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同一メトロエリアで3つ以上のプロバイダーが運用を開始した時点でサポートが必要です。それ以前は、クロスコネクトまたはその他のピアリング契約を使用して他のプロバイダーと相互接続できます。 | -| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | -| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | +| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同一メトロエリアで3つ以上のプロバイダーが運用する場合にサポートが必要です。それ以前は、クロスコネクトやその他のピアリング手段を使用して他のプロバイダーと相互接続できます。 | +| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーにより決定。 | +| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーにより決定。 | #### DZDネットワークハードウェア | メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | はい | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムに問題がある場合、代替品が使用できる可能性があります。 | +| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムが厳しい場合、代替品が可能な場合があります。 | --- @@ -148,7 +148,7 @@ DoubleZeroでは、ネットワークコントリビューターが2つの終端 | メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 16 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。FPGAの接続には100Gが必要です。 | +| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 16 | ケーブルとオプティクスの選択はコントリビューターの裁量で可能。FPGA接続には100Gが必要。 | --- @@ -156,8 +156,8 @@ DoubleZeroでは、ネットワークコントリビューターが2つの終端 | メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 2 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 2 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | +| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 2 | ケーブルとオプティクスの選択はコントリビューターの裁量で可能。 | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 2 | ケーブルとオプティクスの選択はコントリビューターの裁量で可能。 | --- @@ -165,13 +165,13 @@ DoubleZeroでは、ネットワークコントリビューターが2つの終端 | IPアドレス | 最小サブネットサイズ | DZ要件 | 備考 | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にこの要件を廃止する可能性があります。 | +| Public IPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にこの要件を排除する可能性があります。 | -DZプロトコル用に/29プール全体が利用可能であることを確認してください。ポイントツーポイントアドレッシングの要件（例：DIAインターフェース上）は、別のアドレスプールで管理してください。 +完全な/29プールがDZプロトコルで利用可能であることを確認してください。DIAインターフェースなどのポイントツーポイントアドレス指定の要件は、別のアドレスプールで管理してください。 ### 10Gbps帯域幅提供 -数量は2つのデータセンターの機器を反映しています。つまり、帯域幅提供1本を展開するために必要なハードウェアの合計です。 +以下の数量は2つのデータセンターの機器を反映しています。つまり、1つの帯域幅提供を展開するために必要なハードウェアの合計です。 #### 機能とポート要件 @@ -179,9 +179,9 @@ DZプロトコル用に/29プール全体が利用可能であることを確認 |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | プライベート帯域幅 | 10G | はい | 1 | | | Direct Internet Access (DIA) | 10G | はい | 2 | | -| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同一メトロエリアで3つ以上のプロバイダーが運用を開始した時点でサポートが必要です。それ以前は、クロスコネクトまたはその他のピアリング契約を使用して他のプロバイダーと相互接続できます。 | -| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | -| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーに基づきます。 | +| DoubleZero eXchange (DZX) | 100G | はい* | 1 | 同一メトロエリアで3つ以上のプロバイダーが運用する場合にサポートが必要です。それ以前は、クロスコネクトやその他のピアリング手段を使用して他のプロバイダーと相互接続できます。 | +| 管理 | | いいえ | 1 | コントリビューター独自の内部管理ポリシーにより決定。 | +| コンソール | | いいえ | 1 | コントリビューター独自の内部管理ポリシーにより決定。 | --- @@ -190,7 +190,7 @@ DZプロトコル用に/29プール全体が利用可能であることを確認 | メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474* | はい | 4 | | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムに問題がある場合、代替品が使用できる可能性があります。 | +| Arista | 7280CR3A | DCS-7280CR3A-32S | はい | 2 | リードタイムが厳しい場合、代替品が可能な場合があります。 | --- @@ -198,7 +198,7 @@ DZプロトコル用に/29プール全体が利用可能であることを確認 | メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 14 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。FPGAの接続には100Gが必要です。 | +| Arista | 100GBASE-LR | QSFP-100G-LR | いいえ | 14 | ケーブルとオプティクスの選択はコントリビューターの裁量で可能。FPGA接続には100Gが必要。 | --- @@ -206,51 +206,51 @@ DZプロトコル用に/29プール全体が利用可能であることを確認 | メーカー | モデル | 型番 | DZ要件 | 数量 | 備考 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 4 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 4 | ケーブリングとオプティクスの選択はコントリビューターの裁量で決定できます。 | +| Arista | 10GBASE-LR | SFP-10G-LR | いいえ | 4 | ケーブルとオプティクスの選択はコントリビューターの裁量で可能。 | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | いいえ | 4 | ケーブルとオプティクスの選択はコントリビューターの裁量で可能。 | --- #### IPアドレス | IPアドレス | 最小サブネットサイズ | DZ要件 | 備考 | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にこの要件を廃止する可能性があります。 | +| Public IPv4 | /29 | はい（エッジ/ハイブリッドDZDの場合） | DIA経由でルーティング可能である必要があります。将来的にこの要件を排除する可能性があります。 | -DZプロトコル用に/29プール全体が利用可能であることを確認してください。ポイントツーポイントアドレッシングの要件（例：DIAインターフェース上）は、別のアドレスプールで管理してください。 +完全な/29プールがDZプロトコルで利用可能であることを確認してください。DIAインターフェースなどのポイントツーポイントアドレス指定の要件は、別のアドレスプールで管理してください。 ### データセンター要件 -#### ラックと電力要件 +#### ラックと電力の要件 -以下の数値は**DZDごと**、つまりデータセンターごとの数値です。100Gまたは10G帯域幅提供では、リンクの各端にDZDを1台配置するため、これを2倍で計画してください。 +以下の数値は**DZDごと**、つまりデータセンターごとのものです。100Gまたは10Gの帯域幅提供では、リンクの各端にDZDを1台配置するため、これを2回分計画してください。 ##### ラックスペース -| アイテム | ラックユニット | 必要時期 | +| 項目 | ラックユニット | 必要時期 | |------|-----------|--------| -| DZDスイッチ（Arista 7280CR3A-32S または 7130LBR） | 1U | 現在 | +| DZDスイッチ（Arista 7280CR3A-32Sまたは7130LBR） | 1U | 現在 | | エッジフィルタリングアプライアンス | 1U | 後日、エッジおよびハイブリッドデバイスのみ | -**DZDごとに2Uを確保してください。** 現在使用しているのは1ユニットです。エッジフィルタリングアプライアンスをラック移動なしでスイッチの隣に設置できるよう、2つ目を空けておいてください。施設の要件に応じて、エアフローとケーブル管理のためのスペースも確保してください。 +**DZDごとに2Uを確保してください。** 1ユニットは現在使用中です。2つ目は空けておき、ラックの移動なしにエッジフィルタリングアプライアンスをスイッチの隣に設置できるようにしてください。施設の要件に応じて、エアフローとケーブル管理のためのスペースも残してください。 ##### 電力 -| アイテム | 一般的な消費電力 | +| 項目 | 一般的な消費電力 | |------|-------------| | Arista 7280CR3A-32S | 約300 W | -| オプティクス（100G QSFPあたり） | 約5 W | +| オプティクス（100G QSFPごと） | 約5 W | -**DZDごとに2 kWを発注し、2つの独立したフィードに分割してください。** 各フィードは単独で全負荷を支えられるようにサイジングしてください。スイッチは冗長電源を備えていますが、フィード障害後にはそのうち1つしか残らない可能性があります。 +**DZDごとに2 kWを、2つの独立した電源フィードに分けて注文してください。** 各フィードが単独で全負荷を支えられるようにサイズを設定してください。スイッチは冗長電源を備えており、フィード障害後に残るのはそのうちの1つだけになる可能性があります。 -2 kWはギリギリではなく余裕のある数値です。現在ほぼすべてのデプロイメントで運用されているスイッチのみのDZDは、すべてのオプティクスを点灯しても500 W未満の消費です。残りの2 kWは、FPGAを搭載し後日設置されるエッジフィルタリングアプライアンス用に確保されています。 +2 kWはタイトではなく余裕のある値です。スイッチのみのDZD（現在のほぼすべてのデプロイメント）は、すべてのオプティクスが稼働した状態でも500 W未満の消費です。残りの2 kWは、FPGAを搭載し後日設置されるエッジフィルタリングアプライアンス用に確保されています。 -!!! warning "電力を過剰に発注しないでください" - 予約した電力は、実際に消費するかどうかに関わらず課金されます。DZDはスイッチング1ラックユニットであり、コンピュートシャーシではないため、ラック位置が供給可能な電力よりもはるかに少ない消費です。DZDごとに2 kWを超える予約は、使用されない容量に対して料金を支払うことを意味します。 +!!! warning "電力を過剰に注文しないでください" + 予約した電力は、実際に使用するかどうかに関わらず課金されます。DZDはスイッチング1ラックユニットであり、コンピュートシャーシではないため、ラック位置が供給可能な電力よりもはるかに少ない消費です。DZDごとに2 kW以上を予約すると、使われない容量に対して支払うことになります。 -!!! note "発注前に自身のハードウェアを確認してください" - これらは当社のデプロイメントに基づくガイドライン数値です。実際の消費電力は、電源構成、点灯するポート数、選択するオプティクスによって異なります。購入する正確なハードウェアのベンダーデータシートに記載されている電源定格で確認してください。 +!!! note "注文前にご自身のハードウェアを確認してください" + これらは当社の実際のデプロイメントからのガイドライン数値です。実際の消費電力は、電源構成、稼働させるポート数、選択するオプティクスによって異なります。購入する正確なハードウェアのベンダーデータシートに記載されている電源定格と照合してください。 - ただし、発注を最小限に削りすぎないでください。電力はラック内で利用可能である必要があり、後からフィードを追加するには通常施設への新規発注が必要となり、数週間かかることがあります。 + また、最低限のギリギリまで注文を削らないでください。電力はラック内で利用可能でなければならず、後からフィードを追加するには通常、施設への新規注文が必要となり、数週間かかることがあります。 --- diff --git a/docs/contribute.ko.md b/docs/contribute.ko.md index 44334e7..9291505 100644 --- a/docs/contribute.ko.md +++ b/docs/contribute.ko.md @@ -6,26 +6,26 @@ description: DoubleZero 네트워크에 용량을 기여하기 위한 하드웨 ## 요약 -사용률이 낮은 광섬유 케이블과 네트워크 하드웨어를 수익화하고자 하는 누구나 DoubleZero 네트워크에 기여할 수 있습니다. 네트워크 기여자는 두 지점 간 전용 대역폭을 제공하고, 각 끝단에서 DoubleZero 호환 장치(DZD)를 운영하며, 각 끝단에서 공용 인터넷 연결을 제공해야 합니다. 또한 네트워크 기여자는 멀티캐스트, 사용자 조회 및 엣지 필터링과 같은 서비스를 제공하기 위해 각 DZD에서 DoubleZero 소프트웨어를 실행해야 합니다. +미활용 광섬유 케이블과 네트워크 하드웨어를 수익화하고자 하는 누구나 DoubleZero 네트워크에 기여할 수 있습니다. 네트워크 기여자는 두 지점 간 전용 대역폭을 제공하고, 각 끝단에서 DoubleZero 호환 장치(DZD)를 운영하며, 각 끝단에서 공용 인터넷 연결을 제공해야 합니다. 또한 네트워크 기여자는 멀티캐스트, 사용자 조회, 엣지 필터링과 같은 서비스를 제공하기 위해 각 DZD에 DoubleZero 소프트웨어를 실행해야 합니다. -DoubleZero 스마트 컨트랙트는 네트워크가 측정되고 토폴로지에 통합될 수 있는 고품질 링크를 유지하도록 보장하는 핵심 요소로, 네트워크 컨트롤러가 다양한 사용자와 엔드포인트 간의 가장 효율적인 종단 간 경로를 개발할 수 있게 합니다. 스마트 컨트랙트가 실행되고 네트워크 장비 및 대역폭이 배포되면, 해당 엔티티는 네트워크 기여자로 분류됩니다. 네트워크 기여자로서 DoubleZero에 참여하는 것의 경제적 측면을 더 깊이 이해하려면 [DoubleZero Economics](https://economics.doublezero.xyz/overview)를 참조하십시오. +DoubleZero 스마트 컨트랙트는 네트워크가 측정 및 토폴로지에 통합할 수 있는 고품질 링크를 유지하도록 보장하는 핵심 요소이며, 이를 통해 네트워크 컨트롤러가 다양한 사용자와 엔드포인트 간 가장 효율적인 종단 간 경로를 개발할 수 있습니다. 스마트 컨트랙트 실행 및 네트워크 장비와 대역폭 배포가 완료되면 해당 주체는 네트워크 기여자로 분류됩니다. 네트워크 기여자로서 DoubleZero에 참여하는 것의 경제적 측면을 더 자세히 이해하려면 [DoubleZero Economics](https://economics.doublezero.xyz/overview)를 참조하십시오. --- ## DoubleZero 네트워크 기여자가 되기 위한 요구 사항 -- 두 데이터 센터 간에 IPv4 연결 및 2048바이트 MTU를 제공할 수 있는 전용 대역폭 -- DoubleZero 프로토콜과 호환되는 DoubleZero Device(DZD) 하드웨어 +- 두 데이터 센터 간 IPv4 연결 및 2048바이트 MTU를 제공할 수 있는 전용 대역폭 +- DoubleZero 프로토콜과 호환되는 DoubleZero Device (DZD) 하드웨어 - 인터넷 및 다른 DoubleZero 네트워크 기여자와의 연결 - DZD에 DoubleZero 소프트웨어 설치 ## 빠른 시작 가이드 -네트워크 기여자로서 DoubleZero를 시작하는 가장 간단한 방법은 DoubleZero에 전용으로 할당할 수 있는 네트워크 용량을 파악하는 것입니다. 용량이 파악되면, DZD를 배포하여 기여자의 네트워크에서 IPv4 도달 가능성과 최소 2048바이트의 MTU만을 의존하는 DoubleZero 오버레이 네트워크를 구성해야 합니다. +네트워크 기여자로서 DoubleZero를 시작하는 가장 간단한 방법은 DoubleZero에 전용으로 할당할 수 있는 네트워크 용량을 식별하는 것입니다. 식별이 완료되면 DZD를 배포하여 DoubleZero 오버레이 네트워크를 구성해야 하며, 이는 기여자의 네트워크에서 IPv4 도달성과 최소 2048바이트의 MTU만을 종속 조건으로 필요로 합니다. -그림 1은 대역폭 및 패킷 송수신·처리 서비스를 기여하는 가장 간단한 모델을 보여줍니다. 각 데이터 센터에 DZD가 배포되어 네트워크 기여자의 내부 네트워크와 인터페이스하며 DoubleZero WAN 연결을 제공합니다. 이는 DoubleZero 사용자를 위한 온램프로 사용되는 로컬 인터넷, 일반적으로 전용 인터넷 접속(DIA) 솔루션으로 보완됩니다. DIA가 DoubleZero 사용자에 대한 접근을 용이하게 하는 선호 옵션이 될 것으로 예상되지만, 서버에 대한 물리적 케이블링, 네트워크 패브릭 확장 등 다양한 연결 모델이 가능합니다. 이러한 옵션을 "자유 선택 방식(CYOA)"이라고 하며, 기여자가 내부 네트워크 정책에 가장 적합한 방식으로 로컬 또는 원격 사용자를 연결할 수 있는 유연성을 제공합니다. +그림 1은 대역폭 및 패킷 전송 및 처리 서비스를 기여하는 가장 간단한 모델을 보여줍니다. 각 데이터 센터에 DZD가 배포되어 네트워크 기여자의 내부 네트워크와 인터페이스하여 DoubleZero WAN 연결을 제공합니다. 이는 DoubleZero 사용자를 위한 온램프로 사용되는 로컬 인터넷, 일반적으로 Direct Internet Access (DIA) 솔루션으로 보완됩니다. DIA가 DoubleZero 사용자에 대한 접근을 제공하는 데 선호되는 옵션이 될 것으로 예상되지만, 서버에 대한 물리적 케이블 연결, 네트워크 패브릭 확장 등 다양한 연결 모델이 가능합니다. 이러한 옵션을 Choose Your Own Adventure (CYOA)라고 하며, 기여자가 내부 네트워크 정책에 가장 적합한 방식으로 로컬 또는 원격 사용자를 연결할 수 있는 유연성을 제공합니다. -모든 네트워크와 마찬가지로, 네트워크 기여자가 고립되어 존재할 수 없으므로 도달 가능성은 아키텍처의 근본적인 부분입니다. 따라서 DZD는 참가자 간의 연속적인 네트워크를 생성하기 위해 DoubleZero Exchange(DZX)에 대한 링크를 *반드시* 가져야 합니다. +모든 네트워크와 마찬가지로 도달성은 아키텍처의 기본적인 부분이며, 네트워크 기여자는 고립되어 존재할 수 없습니다. 따라서 DZD는 참여자 간 연속적인 네트워크를 만들기 위해 DoubleZero Exchange (DZX)에 대한 링크를 *반드시* 보유해야 합니다.
![Image title](images/figure1.png){ width="800" } @@ -37,9 +37,9 @@ DoubleZero 스마트 컨트랙트는 네트워크가 측정되고 토폴로지 네트워크 기여자가 DoubleZero 기여를 확장할 수 있는 방법은 다양하며, 다음을 포함합니다: - 기존 기여의 성능 특성 향상: 대역폭 증가, 지연 시간 감소 -- 동일한 데이터 센터 간 다중 링크 추가 -- 기존 데이터 센터에서 새로운 데이터 센터로의 새 링크 추가 -- 두 개의 새로운 데이터 센터 간 독립적인 새 링크 추가 +- 동일 데이터 센터 간 다중 링크 추가 +- 기존 데이터 센터에서 새 데이터 센터로의 새 링크 추가 +- 두 개의 새 데이터 센터 간 새로운 독립 링크 추가 #### 예시 1: 단일 기여자, 3개 데이터 센터, 2개 링크
@@ -47,11 +47,11 @@ DoubleZero 스마트 컨트랙트는 네트워크가 측정되고 토폴로지
그림 2: 3개 데이터 센터 간 DoubleZero 네트워크 대역폭 기여 - 단일 기여자
-단일 DZD는 DoubleZero에 기여된 다중 링크를 지원할 수 있습니다. 그림 2는 1로 표시된 단일 데이터 센터가 두 개의 서로 다른 원격 데이터 센터 2와 3으로의 대역폭을 종단하는 경우의 잠재적 토폴로지를 보여줍니다. 이 시나리오에서 각 데이터 센터에는 1개의 DZD만 포함됩니다. 모든 DZD는 CYOA 인터페이스로 사용자 온램프를 위해 DIA를 사용합니다. +단일 DZD는 DoubleZero에 기여되는 여러 링크를 지원할 수 있습니다. 그림 2는 데이터 센터 1로 표기된 단일 데이터 센터가 두 개의 서로 다른 원격 데이터 센터 2와 3으로 대역폭을 종단하는 경우의 잠재적 토폴로지를 보여줍니다. 이 시나리오에서 각 데이터 센터에는 1개의 DZD만 포함됩니다. 모든 DZD는 CYOA 인터페이스로 사용자 온램프를 위한 DIA를 사용합니다. #### 예시 2: 단일 기여자, 3개 데이터 센터, 3개 링크 -그림 3은 단일 기여자가 3개 데이터 센터 간에 삼각형 토폴로지로 3개 링크를 배포할 때의 DoubleZero 토폴로지를 설명합니다. 예시 1과 유사한 시나리오에서, 데이터 센터 1, 2, 3에 각각 단일 DZD가 배포되며 각각 2개의 독립적인 네트워크 링크를 지원합니다. 결과적인 토폴로지는 데이터 센터 간의 삼각형 또는 링 구조입니다. +그림 3은 단일 기여자가 3개 데이터 센터 간 삼각형 토폴로지로 3개 링크를 배포할 때의 DoubleZero 토폴로지를 설명합니다. 예시 1과 유사한 시나리오에서 데이터 센터 1, 2, 3에 각각 단일 DZD가 배포되며, 각각 2개의 독립적인 네트워크 링크를 지원합니다. 결과적인 토폴로지는 데이터 센터 간 삼각형 또는 링 형태입니다.
![Image title](images/figure3.png){ width="800" } @@ -60,7 +60,7 @@ DoubleZero 스마트 컨트랙트는 네트워크가 측정되고 토폴로지 ### DoubleZero Exchange -연속적인 네트워크의 생성은 DoubleZero 아키텍처의 근본적인 구성 요소입니다. 기여자는 뉴욕(NYC), 런던(LON) 또는 도쿄(TYO)와 같은 도시인 수도권 내의 DoubleZero Exchange(DZX)를 통해 인터페이스합니다. DZX는 인터넷 익스체인지와 유사한 네트워크 패브릭으로, 피어링과 라우트 교환을 가능하게 합니다. +연속적인 네트워크 구축은 DoubleZero 아키텍처의 기본 구성 요소입니다. 기여자는 뉴욕(NYC), 런던(LON), 도쿄(TYO)와 같은 도시인 대도시 지역 내의 DoubleZero Exchange (DZX)를 통해 인터페이스합니다. DZX는 Internet Exchange와 유사한 네트워크 패브릭으로, 피어링 및 경로 교환을 가능하게 합니다. 그림 4에서 네트워크 기여자 1은 데이터 센터 1, 2, 3에서 운영하고, 네트워크 기여자 2는 데이터 센터 2, 4, 5에서 운영합니다. 데이터 센터 2에서 상호 연결함으로써 DoubleZero 네트워크 도달 범위가 5개의 연속적인 데이터 센터로 확장됩니다. @@ -71,13 +71,13 @@ DoubleZero 스마트 컨트랙트는 네트워크가 측정되고 토폴로지 ### 대역폭 기여 옵션 -DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 종단 데이터 센터의 DZD 간 보장된 대역폭, 지연 시간 및 지터 프로파일을 통한 통합 연결을 제공할 것을 요구합니다. DoubleZero는 네트워크 기여자가 기여를 어떻게 구현하는지 규정하지 않지만, 다음 섹션에서 기여자의 독자적 판단에 따라 사용할 수 있는 참고 옵션을 제공합니다. +DoubleZero는 네트워크 기여자가 스마트 컨트랙트를 통해 표현된 두 종단 데이터 센터의 DZD 간 보장된 대역폭, 지연 시간 및 지터 프로파일을 통해 통합 연결을 제공할 것을 요구합니다. DoubleZero는 네트워크 기여자가 기여를 어떻게 구현하는지를 의무화하지 않지만, 다음 섹션에서 기여자의 자체 재량에 따라 사용할 수 있는 참고 옵션을 제공합니다. 네트워크 기여자가 고려해야 할 중요한 영역은 다음과 같습니다: -- DoubleZero 서비스의 네트워크 성능 보장 능력: 대역폭, 지연 시간, 지터 -- 기존 내부 네트워크 서비스로부터의 분리 -- IPv4 주소 충돌, 특히 터널 언더레이 주소 공간과의 충돌 +- DoubleZero 서비스의 네트워크 성능 보장 능력: 대역폭, 지연 시간 및 지터 +- 기존 내부 네트워크 서비스와의 분리 +- 특히 터널 언더레이 주소 공간과의 IPv4 주소 충돌 - 가동 시간 및 가용성 - CAPEX 및 OPEX 고려 사항 @@ -87,13 +87,13 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두
그림 5: 레이어 1 광학 서비스
-레이어 1 대역폭, 보다 공식적으로 파장 서비스라고 불리는 것은, DWDM, CWDM 또는 광 멀티플렉서(MUX)를 통해 기존 광학 인프라에 전용 용량을 프로비저닝하는 것입니다. 그림 5에서 DZD는 L1 MUX에 케이블링된 컬러 광학 모듈을 사용하며, 이는 DZD 파장을 기존 다크 파이버에 인터리빙합니다. +레이어 1 대역폭은 보다 정식으로는 파장 서비스로 설명되며, DWDM, CWDM 또는 광 멀티플렉서(MUX)를 통해 기존 광학 인프라에 전용 용량을 프로비저닝할 수 있습니다. 그림 5에서 DZD는 L1 MUX에 케이블로 연결된 컬러드 광학 모듈을 사용하며, 기존 다크 파이버에 DZD 파장을 인터리브합니다. -이 솔루션은 이미 기존 코어 네트워크를 운영하고 있는 네트워크 기여자에게 많은 이점을 제공합니다. 반복적인 운영 변경과 추가 CAPEX 및 OPEX 요구 사항이 적당합니다. 이 옵션은 네트워크 기여자의 네트워크 서비스로부터의 분리를 제공하는 데 특히 강력합니다. +이 솔루션은 이미 기존 코어 네트워크를 운영하는 네트워크 기여자에게 다양한 이점을 제공합니다. 반복적인 운영 변경 사항과 추가 CAPEX 및 OPEX 요구 사항이 적당합니다. 이 옵션은 네트워크 기여자의 네트워크 서비스와의 분리를 제공하는 데 특히 강력합니다. #### 패킷 스위칭 대역폭 -패킷 스위칭 네트워크는 비즈니스 애플리케이션을 지원하는 표준 라우팅 및 스위칭 프로토콜을 실행하는 일반적인 엔터프라이즈 네트워크로 간주될 수 있습니다. VLAN 태그를 사용한 레이어 2(L2) 확장 등 연결을 달성하는 다양한 네트워킹 기술이 있습니다. +패킷 스위칭 네트워크는 비즈니스 애플리케이션을 지원하는 표준 라우팅 및 스위칭 프로토콜을 실행하는 일반적인 엔터프라이즈 네트워크로 간주할 수 있습니다. 예를 들어 VLAN 태그를 사용한 레이어 2 (L2) 확장 등 연결을 달성하는 다양한 네트워킹 기술이 있습니다. ##### L2 확장
@@ -101,9 +101,9 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두
그림 6: 패킷 스위칭 네트워크 - L2 확장
-그림 6에 표시된 L2 확장은 VLAN 태깅을 통해 구현할 수 있습니다. DZD의 포트를 기여자의 내부 네트워크 스위치에 케이블링하고, 스위치 포트를 예를 들어 VLAN 10의 액세스 포트로 설정할 수 있습니다. 802.1q 태깅을 통해 이 VLAN은 기여자의 네트워크에서 여러 스위치 홉을 거쳐 전달되어 원격 DZD와 인터페이스하는 스위치에서 종단됩니다. +그림 6에 표시된 L2 확장은 VLAN 태깅을 통해 구현할 수 있습니다. DZD의 포트를 기여자의 내부 네트워크 스위치에 케이블로 연결하고, 스위치 포트를 예를 들어 VLAN 10의 액세스 포트로 설정할 수 있습니다. 802.1q 태깅을 통해 이 VLAN은 기여자 네트워크의 여러 스위치 홉을 통해 전달되어 원격 DZD와 인터페이스하는 스위치에서 종단됩니다. -이 솔루션은 널리 지원되고 구현이 비교적 쉬우면서도 DoubleZero와 내부 레이어 3 서비스 간의 분리를 제공한다는 이점이 있습니다. 대역폭은 기여자 내부 스위치 또는 라우터의 인터페이스 속도에 따라 제어할 수 있습니다. QoS(Quality of Service) 또는 기타 트래픽 관리 정책과 같은 기술을 통해 공유 내부 L2 네트워크 전반의 성능을 신중하게 고려해야 합니다. 그러나 기여자의 코어 네트워크 내에 기존 용량이 있는 경우 추가 CAPEX 및 OPEX 투자는 적당할 것입니다. +이 솔루션은 널리 지원되고 비교적 구현이 쉬우면서도 DoubleZero와 내부 레이어 3 서비스 간 분리를 생성한다는 이점이 있습니다. 대역폭은 기여자의 내부 스위치 또는 라우터의 인터페이스 속도에 따라 제어할 수 있습니다. Quality of Service (QoS) 또는 기타 트래픽 관리 정책과 같은 기술을 통해 공유 내부 L2 네트워크 전반의 성능에 대한 신중한 고려가 필요합니다. 그러나 기여자의 코어 네트워크에 기존 용량이 있는 경우 추가 CAPEX 및 OPEX 투자는 적당해야 합니다. #### 전용 제3자 대역폭
@@ -111,9 +111,9 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두
그림 7: 전용 제3자 대역폭
-가용 용량을 재사용하는 것이 많은 네트워크 기여자에게 매력적이지만, 새로 확보한 대역폭을 DoubleZero에 전용으로 할당할 수도 있습니다. 이러한 시나리오에서 DZD는 기여자의 내부 장비 없이 제3자 통신사에 직접 연결됩니다(그림 7). +가용 용량의 재사용이 많은 네트워크 기여자에게 매력적일 수 있지만, 새로 확보한 대역폭을 DoubleZero에 전용으로 할당할 수도 있습니다. 이러한 시나리오에서 DZD는 기여자의 내부 장치 없이 제3자 통신 사업자에 직접 연결됩니다(그림 7). -이 옵션은 DoubleZero를 위한 전용 대역폭을 보장하고, 운영이 간단하며, 다른 네트워크 서비스로부터 완전한 분리를 보장한다는 점에서 매력적입니다. 이 옵션은 OPEX 증가가 가장 크고 제3자 통신사와의 새로운 서비스 계약이 필요할 가능성이 높습니다. +이 옵션은 DoubleZero를 위한 전용 대역폭을 보장하고, 운영적으로 단순하며, 다른 네트워크 서비스와의 완전한 분리를 보장하므로 매력적입니다. 이 옵션은 OPEX 증가가 가장 클 가능성이 높으며 제3자 통신 사업자와의 새로운 서비스 계약이 필요합니다. --- @@ -123,21 +123,21 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 아래 수량은 2개 데이터 센터에 필요한 장비를 반영합니다. 즉, 대역폭 기여를 위해 1개의 광섬유 케이블을 배포하는 데 필요한 총 하드웨어입니다. -??? warning "*모든 FPGA는 최종 테스트를 거칩니다. 10G 기여는 내장 듀얼 Virtex® UltraScale+™ FPGA를 갖춘 Arista 7130LBR 스위치를 사용하여 지원될 수 있습니다(질문이 있으시면 DoubleZero Foundation / Malbec Labs가 기꺼이 추가 정보를 제공해 드립니다)." +??? warning "*모든 FPGA는 최종 테스트 대상입니다. 10G 기여는 내장 듀얼 Virtex® UltraScale+™ FPGA가 포함된 Arista 7130LBR 스위치를 사용하여 지원될 수 있습니다 (질문이 있으시면 DoubleZero Foundation / Malbec Labs가 기꺼이 추가 정보를 제공합니다)." #### 기능 및 포트 요구 사항 -| 기능 | 포트 속도 | DZ 요구 사항 | 수량 | 비고 | +| 기능 | 포트 속도 | DZ 필수 여부 | 수량 | 비고 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Private Bandwidth | 100G | 예 | 1 | | | Direct Internet Access (DIA) | 10G | 예 | 2 | | -| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일 수도권에서 3개 이상의 제공자가 운영되면 반드시 지원해야 합니다. 그 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용하여 다른 제공자와 상호 연결할 수 있습니다. | +| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일 대도시 지역에서 3개 이상의 제공자가 운영되면 반드시 지원되어야 하며, 그 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용하여 다른 제공자와 상호 연결할 수 있습니다. | | Management | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | | Console | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | #### DZD 네트워크 하드웨어 -| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | +| 제조사 | 모델 | 부품 번호 | DZ 필수 여부 | 수량 | 비고 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | 예 | 4 | | | Arista | 7280CR3A | DCS-7280CR3A-32S | 예 | 2 | 리드 타임이 어려운 경우 대안이 가능할 수 있습니다. | @@ -146,28 +146,28 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 #### 광학 모듈 - 100G -| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | +| 제조사 | 모델 | 부품 번호 | DZ 필수 여부 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 16 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. FPGA 연결에 100G가 필요합니다. | +| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 16 | 케이블 및 광학 모듈 선택은 기여자의 재량에 따릅니다. FPGA 연결에는 100G가 필요합니다. | --- #### 광학 모듈 - 10G -| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | +| 제조사 | 모델 | 부품 번호 | DZ 필수 여부 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 2 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 2 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | +| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 2 | 케이블 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 2 | 케이블 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | --- #### IP 주소 지정 -| IP 주소 지정 | 최소 서브넷 크기 | DZ 요구 사항 | 비고 | +| IP 주소 지정 | 최소 서브넷 크기 | DZ 필수 여부 | 비고 | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | 예 (엣지/하이브리드 DZD용) | DIA를 통해 라우팅 가능해야 합니다. 향후 이 요구 사항이 제거될 수 있습니다. | +| Public IPv4 | /29 | 예 (엣지/하이브리드 DZD의 경우) | DIA를 통해 라우팅 가능해야 합니다. 시간이 지남에 따라 이 필요성을 제거할 수 있습니다. | -전체 /29 풀이 DZ 프로토콜에 사용 가능한지 확인하십시오. 포인트 투 포인트 주소 지정 요구 사항(예: DIA 인터페이스)은 다른 주소 풀을 통해 관리해야 합니다. +전체 /29 풀이 DZ 프로토콜에 사용 가능한지 확인하십시오. DIA 인터페이스 등에 대한 점대점 주소 지정 요구 사항은 다른 주소 풀을 통해 관리해야 합니다. ### 10Gbps 대역폭 기여 @@ -175,11 +175,11 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 #### 기능 및 포트 요구 사항 -| 기능 | 포트 속도 | DZ 요구 사항 | 수량 | 비고 | +| 기능 | 포트 속도 | DZ 필수 여부 | 수량 | 비고 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Private Bandwidth | 10G | 예 | 1 | | | Direct Internet Access (DIA) | 10G | 예 | 2 | | -| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일 수도권에서 3개 이상의 제공자가 운영되면 반드시 지원해야 합니다. 그 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용하여 다른 제공자와 상호 연결할 수 있습니다. | +| DoubleZero eXchange (DZX) | 100G | 예* | 1 | 동일 대도시 지역에서 3개 이상의 제공자가 운영되면 반드시 지원되어야 하며, 그 이전에는 크로스 커넥트 또는 기타 피어링 방식을 사용하여 다른 제공자와 상호 연결할 수 있습니다. | | Management | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | | Console | | 아니오 | 1 | 기여자의 자체 내부 관리 정책에 따라 결정됩니다. | @@ -187,7 +187,7 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 #### 하드웨어 -| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | +| 제조사 | 모델 | 부품 번호 | DZ 필수 여부 | 수량 | 비고 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474* | 예 | 4 | | | | Arista | 7280CR3A | DCS-7280CR3A-32S | 예 | 2 | 리드 타임이 어려운 경우 대안이 가능할 수 있습니다. | @@ -196,33 +196,33 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 #### 광학 모듈 - 100G -| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | +| 제조사 | 모델 | 부품 번호 | DZ 필수 여부 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 14 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. FPGA 연결에 100G가 필요합니다. | +| Arista | 100GBASE-LR | QSFP-100G-LR | 아니오 | 14 | 케이블 및 광학 모듈 선택은 기여자의 재량에 따릅니다. FPGA 연결에는 100G가 필요합니다. | --- #### 광학 모듈 - 10G -| 제조사 | 모델 | 부품 번호 | DZ 요구 사항 | 수량 | 비고 | +| 제조사 | 모델 | 부품 번호 | DZ 필수 여부 | 수량 | 비고 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 4 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 4 | 케이블링 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | +| Arista | 10GBASE-LR | SFP-10G-LR | 아니오 | 4 | 케이블 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 아니오 | 4 | 케이블 및 광학 모듈 선택은 기여자의 재량에 따릅니다. | --- #### IP 주소 지정 -| IP 주소 지정 | 최소 서브넷 크기 | DZ 요구 사항 | 비고 | +| IP 주소 지정 | 최소 서브넷 크기 | DZ 필수 여부 | 비고 | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | 예 (엣지/하이브리드 DZD용) | DIA를 통해 라우팅 가능해야 합니다. 향후 이 요구 사항이 제거될 수 있습니다. | +| Public IPv4 | /29 | 예 (엣지/하이브리드 DZD의 경우) | DIA를 통해 라우팅 가능해야 합니다. 시간이 지남에 따라 이 필요성을 제거할 수 있습니다. | -전체 /29 풀이 DZ 프로토콜에 사용 가능한지 확인하십시오. 포인트 투 포인트 주소 지정 요구 사항(예: DIA 인터페이스)은 다른 주소 풀을 통해 관리해야 합니다. +전체 /29 풀이 DZ 프로토콜에 사용 가능한지 확인하십시오. DIA 인터페이스 등에 대한 점대점 주소 지정 요구 사항은 다른 주소 풀을 통해 관리해야 합니다. ### 데이터 센터 요구 사항 -#### 랙 및 전력 요구 사항 +#### 랙 및 전원 요구 사항 -아래 수치는 **DZD당**, 즉 데이터 센터당 기준입니다. 100G 또는 10G 대역폭 기여는 링크의 각 끝에 하나의 DZD를 배치하므로, 이를 두 번 계획하십시오. +아래 수치는 **DZD당**, 즉 데이터 센터당 기준입니다. 100G 또는 10G 대역폭 기여는 링크의 각 끝에 DZD 1개를 배치하므로 이를 두 번 계획하십시오. ##### 랙 공간 @@ -231,18 +231,18 @@ DoubleZero는 네트워크 기여자에게 스마트 컨트랙트를 통해 두 | DZD 스위치 (Arista 7280CR3A-32S 또는 7130LBR) | 1U | 현재 | | 엣지 필터링 어플라이언스 | 1U | 추후, 엣지 및 하이브리드 장치에만 해당 | -**DZD당 2U를 확보하십시오.** 현재 1유닛이 사용 중입니다. 엣지 필터링 어플라이언스를 랙 이동 없이 스위치 옆에 설치할 수 있도록 두 번째 유닛을 비워 두십시오. 시설 요구 사항에 따라 공기 흐름 및 케이블 관리를 위한 여유 공간을 남겨 두십시오. +**DZD당 2U를 확보하십시오.** 1유닛은 현재 사용 중입니다. 엣지 필터링 어플라이언스가 랙 이동 없이 스위치 옆에 설치될 수 있도록 두 번째 유닛을 비워 두십시오. 시설 요구 사항에 따라 공기 흐름과 케이블 관리를 위한 공간을 남겨 두십시오. -##### 전력 +##### 전원 -| 항목 | 일반적 소비 전력 | +| 항목 | 일반적인 소비 전력 | |------|-------------| | Arista 7280CR3A-32S | ~300 W | | 광학 모듈, 100G QSFP당 | ~5 W | -**DZD당 2 kW를 주문하고, 두 개의 독립적인 전원 피드에 분배하십시오.** 각 피드가 단독으로 전체 부하를 감당할 수 있도록 크기를 설정하십시오. 스위치는 이중화 전원 공급 장치를 운영하며, 피드 장애 후에는 하나만 남을 수 있습니다. +**DZD당 2 kW를 주문하고, 2개의 독립된 전원 피드에 분배하십시오.** 각 피드가 단독으로 전체 부하를 감당할 수 있도록 크기를 설정하십시오. 스위치는 이중화 전원 공급 장치를 실행하며, 피드 장애 후에는 그 중 하나만 남을 수 있습니다. -2 kW는 빠듯하지 않고 여유 있는 수치입니다. 현재 거의 모든 배포에서 실행되는 스위치 전용 DZD는 모든 광학 모듈이 켜져 있어도 500 W 미만을 소비합니다. 나머지 2 kW는 FPGA를 포함하며 추후 설치되는 엣지 필터링 어플라이언스를 위해 예약되어 있습니다. +2 kW는 빠듯하기보다는 여유 있는 수준입니다. 현재 거의 모든 배포에서 사용되는 스위치 전용 DZD는 모든 광학 모듈이 켜진 상태에서도 500 W 미만을 소비합니다. 나머지 2 kW는 FPGA를 포함하며 추후 설치되는 엣지 필터링 어플라이언스를 위해 예약됩니다. -!!! warning "전력을 과도하게 주문하지 마십시오" - 사용 여부에 관계없이 예약한 전력에 대해 비용을 지불합니다. DZD는 컴퓨트 섀시가 아닌 단일 랙 유닛의 스위칭이므로, 랙 위치가 공급할 수 있는 것보다 훨씬 적은 전력을 소비합니다. DZD당 2 kW 이상을 예약하면 유 \ No newline at end of file +!!! warning "전원을 과다 주문하지 마십시오" + 사용 여부와 관계없이 예약한 전력에 대해 비용을 지불합니다. DZD는 컴퓨트 섀시가 아니라 단일 랙 유닛의 스위칭이므로 랙 위치에서 공급할 수 있는 것보다 훨씬 적은 전력을 소비합니다. DZD당 2 kW 이상을 예약하면 유휴 상태로 있는 용량 \ No newline at end of file diff --git a/docs/contribute.pt.md b/docs/contribute.pt.md index 71cfc76..d98f708 100644 --- a/docs/contribute.pt.md +++ b/docs/contribute.pt.md @@ -1,14 +1,14 @@ --- -description: Requisitos de hardware, largura de banda e conectividade, além da arquitetura para contribuir com capacidade para a rede DoubleZero. +description: Requisitos de hardware, largura de banda e conectividade, bem como arquitetura para contribuir com capacidade para a rede DoubleZero. --- # Requisitos e Arquitetura para Contribuidores ## Resumo -Qualquer pessoa que deseje monetizar seus cabos de fibra óptica e hardware de rede subutilizados pode contribuir para a rede DoubleZero. Os contribuidores de rede devem fornecer largura de banda dedicada entre dois pontos, operar dispositivos compatíveis com DoubleZero (DZDs) em cada extremidade e uma conexão à internet pública em cada extremidade. Os contribuidores de rede também devem executar o software DoubleZero em cada DZD para fornecer serviços como multicast, consulta de usuários e filtragem de borda. +Qualquer pessoa que deseje monetizar seus cabos de fibra óptica e hardware de rede subutilizados pode contribuir para a rede DoubleZero. Os contribuidores de rede devem fornecer largura de banda dedicada entre dois pontos, operar dispositivos compatíveis com DoubleZero (DZDs) em cada extremidade e uma conexão à internet pública em cada extremidade. Os contribuidores de rede também devem executar o software DoubleZero em cada DZD para fornecer serviços como multicast, busca de usuários e filtragem de borda. -O smart contract DoubleZero é a pedra angular para garantir que a rede mantenha links de alta qualidade que possam ser medidos e integrados à topologia, permitindo que nossos controladores de rede desenvolvam o caminho fim-a-fim mais eficiente entre nossos diferentes usuários e endpoints. Após a execução do smart contract e a implantação dos equipamentos de rede e largura de banda, uma entidade é classificada como contribuidor de rede. Consulte [DoubleZero Economics](https://economics.doublezero.xyz/overview) para entender melhor a economia por trás da participação no DoubleZero como contribuidor de rede. +O contrato inteligente DoubleZero é a pedra angular para garantir que a rede mantenha links de alta qualidade que possam ser medidos e integrados à topologia, permitindo que nossos controladores de rede desenvolvam o caminho ponta a ponta mais eficiente entre nossos diferentes usuários e endpoints. Após a execução do contrato inteligente e implantação do equipamento de rede e largura de banda, uma entidade é classificada como contribuidor de rede. Consulte [DoubleZero Economics](https://economics.doublezero.xyz/overview) para entender melhor a economia por trás da participação no DoubleZero como contribuidor de rede. --- @@ -21,11 +21,11 @@ O smart contract DoubleZero é a pedra angular para garantir que a rede mantenha ## Guia de Início Rápido -Como contribuidor de rede, a maneira mais simples de começar no DoubleZero é identificando capacidade em sua rede que possa ser dedicada ao DoubleZero. Uma vez identificada, os DZDs devem ser implantados, facilitando a rede overlay DoubleZero que requer apenas alcançabilidade IPv4 e um MTU mínimo de 2048 bytes como suas dependências da rede do contribuidor. +Como contribuidor de rede, a maneira mais simples de começar no DoubleZero é identificando capacidade na sua rede que possa ser dedicada ao DoubleZero. Uma vez identificada, os DZDs devem ser implantados, facilitando a rede overlay DoubleZero que requer apenas alcançabilidade IPv4 e um MTU mínimo de 2048 bytes como suas dependências da rede do contribuidor. -A Figura 1 destaca o modelo mais simples para contribuição de largura de banda e serviços de envio e processamento de pacotes. Um DZD é implantado em cada data center, conectando-se à rede interna do contribuidor de rede para fornecer conectividade WAN DoubleZero. Isso é complementado por internet local, tipicamente uma solução de Acesso Direto à Internet (DIA), que é usada como pontos de acesso para os usuários DoubleZero. Embora se espere que o DIA seja a opção preferida para facilitar o acesso aos usuários do DoubleZero, diversos modelos de conectividade são possíveis, por exemplo, cabeamento físico para servidores, extensão de fabric de rede, etc. Nos referimos a essas opções como Choose Your Own Adventure (CYOA), proporcionando ao contribuidor flexibilidade para conectar usuários locais ou remotos da maneira que melhor se adeque às suas políticas internas de rede. +A Figura 1 destaca o modelo mais simples para contribuição de largura de banda e serviços de envio e processamento de pacotes. Um DZD é implantado em cada data center, fazendo interface com a rede interna do contribuidor de rede para fornecer conectividade WAN DoubleZero. Isso é complementado por internet local, tipicamente uma solução de Acesso Direto à Internet (DIA), que é usada como pontos de entrada para usuários DoubleZero. Embora se espere que o DIA seja a opção preferida para facilitar o acesso aos usuários do DoubleZero, diversos modelos de conectividade são possíveis, por exemplo, cabeamento físico para servidores, extensão de fabric de rede, etc. Referimo-nos a essas opções como Choose Your Own Adventure (CYOA), proporcionando ao contribuidor flexibilidade para conectar usuários locais ou remotos da maneira que melhor se adeque às suas políticas internas de rede. -Como em qualquer rede, a alcançabilidade é uma parte fundamental da arquitetura, pois os contribuidores de rede não podem operar isoladamente. Sendo assim, o DZD *deve* ter um link para um DoubleZero Exchange (DZX) para criar uma rede contígua entre os participantes. +Como em qualquer rede, a alcançabilidade é uma parte fundamental da arquitetura, pois os contribuidores de rede não podem existir isoladamente. Assim, o DZD *deve* ter um link para um DoubleZero Exchange (DZX) para criar uma rede contígua entre os participantes.
![Image title](images/figure1.png){ width="800" } @@ -34,9 +34,9 @@ Como em qualquer rede, a alcançabilidade é uma parte fundamental da arquitetur ### Exemplos de Contribuições -As formas pelas quais um contribuidor de rede pode expandir suas contribuições ao DoubleZero são muitas, incluindo: +As maneiras pelas quais um contribuidor de rede pode expandir suas contribuições ao DoubleZero são muitas, incluindo: -- Melhorar as características de desempenho de suas contribuições existentes: aumentar a largura de banda, reduzir a latência +- Melhorar as características de desempenho de suas contribuições existentes: aumentar largura de banda, reduzir latência - Adicionar múltiplos links entre os mesmos data centers - Adicionar um novo link de um data center existente para um novo data center - Adicionar um novo link independente entre dois novos data centers @@ -47,7 +47,7 @@ As formas pelas quais um contribuidor de rede pode expandir suas contribuições
Figura 2: Contribuição de Largura de Banda da Rede DoubleZero Entre 3 Data Centers - Contribuidor Único
-Um único DZD pode suportar múltiplos links contribuídos ao DoubleZero. A Figura 2 ilustra uma topologia potencial se um único data center, denominado 1, termina largura de banda para dois data centers remotos diferentes, 2 e 3. Neste cenário, cada data center contém apenas 1 DZD. Todos os DZDs estão usando DIA para pontos de acesso de usuários como sua interface CYOA. +Um único DZD pode suportar múltiplos links contribuídos ao DoubleZero. A Figura 2 ilustra uma topologia potencial se um único data center, denominado como 1, terminar largura de banda para dois data centers remotos diferentes, 2 e 3. Neste cenário, cada data center contém apenas 1 DZD. Todos os DZDs estão usando DIA para pontos de entrada de usuários como sua interface CYOA. #### Exemplo 2: Contribuidor Único, 3 Data Centers, Três Links @@ -62,7 +62,7 @@ A Figura 3 descreve a topologia DoubleZero quando um único contribuidor implant A criação de uma rede contígua é um bloco fundamental da arquitetura DoubleZero. Os contribuidores se interconectam via um DoubleZero Exchange (DZX) dentro de uma área metropolitana, que é uma cidade como Nova York (NYC), Londres (LON) ou Tóquio (TYO). Um DZX é um fabric de rede semelhante a um Internet Exchange, permitindo peering e troca de rotas. -Na figura 4, o contribuidor de rede 1 opera nos data centers 1, 2 e 3, enquanto o contribuidor de rede 2 opera nos data centers 2, 4 e 5. Ao se interconectarem no data center 2, o alcance da rede DoubleZero aumenta para 5 data centers contíguos. +Na Figura 4, o contribuidor de rede 1 opera nos data centers 1, 2 e 3, enquanto o contribuidor de rede 2 opera nos data centers 2, 4 e 5. Ao se interconectar no data center 2, o alcance da rede DoubleZero aumenta para 5 data centers contíguos.
![Image title](images/figure4.png){ width="1000" } @@ -71,9 +71,9 @@ Na figura 4, o contribuidor de rede 1 opera nos data centers 1, 2 e 3, enquanto ### Opções de Contribuição de Largura de Banda -O DoubleZero requer que um contribuidor de rede ofereça conectividade integrada via um perfil garantido de largura de banda, latência e jitter entre DZDs em dois data centers terminais, expresso por meio de um smart contract. O DoubleZero não determina como um contribuidor de rede implementa sua contribuição; no entanto, nas seções a seguir, fornecemos opções indicativas para uso a seu exclusivo critério. +O DoubleZero requer que um contribuidor de rede ofereça conectividade integrada via um perfil garantido de largura de banda, latência e jitter entre DZDs em dois data centers terminais, expresso por meio de um contrato inteligente. O DoubleZero não determina como um contribuidor de rede implementa sua contribuição; no entanto, nas seções seguintes, fornecemos opções indicativas para uso a seu exclusivo critério. -Áreas importantes a considerar para um contribuidor de rede podem ser: +Áreas importantes a serem consideradas por um contribuidor de rede podem ser: - Capacidade de garantir o desempenho de rede do serviço DoubleZero: largura de banda, latência e jitter - Segregação de seus serviços de rede internos existentes @@ -87,23 +87,23 @@ O DoubleZero requer que um contribuidor de rede ofereça conectividade integrada
Figura 5: Serviços Ópticos Camada 1
-A largura de banda Camada 1, mais formalmente descrita como serviços de comprimento de onda, pode contemplar capacidade dedicada provisionada em uma infraestrutura óptica existente, como DWDM, CWDM ou via multiplexadores ópticos (MUX). Na figura 5, os DZDs usam uma óptica colorida que é cabeada a um MUX L1, que intercala o comprimento de onda do DZD em uma fibra escura existente. +A largura de banda Camada 1, mais formalmente descrita como serviços de comprimento de onda, pode ter capacidade dedicada provisionada em uma infraestrutura óptica existente, como DWDM, CWDM ou via multiplexadores ópticos (MUX). Na Figura 5, os DZDs usam uma óptica colorida que é cabeada a um MUX L1, que intercala o comprimento de onda do DZD em uma fibra escura existente. -Esta solução tem inúmeros benefícios para contribuidores de rede que já operam uma rede core existente. As mudanças operacionais incrementais, bem como os requisitos adicionais de CAPEX e OPEX, são modestos. Esta opção é particularmente robusta em oferecer segregação dos serviços de rede do contribuidor. +Esta solução tem inúmeros benefícios para contribuidores de rede que já operam uma rede core existente. As mudanças operacionais iterativas, bem como os requisitos adicionais de CAPEX e OPEX, são modestos. Esta opção é particularmente robusta em oferecer segregação dos serviços de rede do contribuidor. -#### Largura de Banda por Comutação de Pacotes +#### Largura de Banda Comutada por Pacotes -Redes de comutação de pacotes podem ser consideradas uma rede empresarial típica, executando protocolos padrão de roteamento e switching que suportam aplicações de negócios. Existem inúmeras tecnologias de rede que alcançam conectividade, por exemplo, extensões de camada 2 (L2) usando tags VLAN. +Redes comutadas por pacotes podem ser consideradas uma rede corporativa típica, executando protocolos padrão de roteamento e comutação que suportam aplicações de negócios. Existem inúmeras tecnologias de rede que alcançam conectividade, por exemplo, extensões de camada 2 (L2) usando tags VLAN. ##### Extensão L2
![Image title](images/figure6.png){ width="800" } -
Figura 6: Redes de Comutação de Pacotes - Extensão L2
+
Figura 6: Redes Comutadas por Pacotes - Extensão L2
-Uma extensão L2, conforme mostrado na Figura 6, pode ser facilitada por meio de marcação VLAN. A porta de um DZD pode ser cabeada ao switch de rede interna de um contribuidor, com a porta do switch sendo configurada como porta de acesso, por exemplo, na VLAN 10. Através da marcação 802.1q, esta VLAN pode ser transportada por múltiplos saltos de switch na rede do contribuidor, terminando no switch que faz interface com o DZD remoto. +Uma extensão L2, conforme mostrado na Figura 6, pode ser facilitada através de marcação VLAN. A porta de um DZD pode ser cabeada ao switch da rede interna do contribuidor, com a porta do switch sendo configurada como uma porta de acesso em, por exemplo, VLAN 10. Através da marcação 802.1q, esta VLAN pode ser transportada por múltiplos saltos de switch na rede do contribuidor, terminando no switch que faz interface com o DZD remoto. -Esta solução se beneficia por ser amplamente suportada e relativamente fácil de implementar, criando segmentação entre o DoubleZero e os serviços internos de camada 3. A largura de banda pode ser controlada com base na velocidade da interface do switch ou roteador interno do contribuidor. Deve-se dar atenção cuidadosa ao desempenho na rede L2 interna compartilhada por meio de tecnologias como Quality of Service (QoS) ou outras políticas de gerenciamento de tráfego. No entanto, os investimentos adicionais de CAPEX e OPEX devem ser modestos se existir capacidade disponível na rede core do contribuidor. +Esta solução se beneficia por ser amplamente suportada e relativamente fácil de implementar, criando segmentação entre o DoubleZero e os serviços internos de camada 3. A largura de banda pode ser controlada com base na velocidade da interface do switch ou roteador interno do contribuidor. Consideração cuidadosa deve ser dada ao desempenho na rede L2 interna compartilhada através de tecnologias como Qualidade de Serviço (QoS) ou outras políticas de gerenciamento de tráfego. No entanto, investimentos adicionais de CAPEX e OPEX devem ser modestos se capacidade existente estiver disponível na rede core do contribuidor. #### Largura de Banda Dedicada de Terceiros
@@ -111,7 +111,7 @@ Esta solução se beneficia por ser amplamente suportada e relativamente fácil
Figura 7: Largura de Banda Dedicada de Terceiros
-Embora reutilizar capacidade disponível seja atraente para muitos contribuidores de rede, também é possível dedicar largura de banda recém-adquirida ao DoubleZero. Em tal cenário, o DZD se conectaria diretamente à operadora de terceiros sem nenhum dispositivo interno do contribuidor no caminho (figura 7). +Embora a reutilização da capacidade disponível seja atraente para muitos contribuidores de rede, também é possível dedicar largura de banda recém-adquirida ao DoubleZero. Em tal cenário, o DZD se conectaria diretamente à operadora de terceiros sem nenhum dispositivo interno do contribuidor em linha (Figura 7). Esta opção é atraente pois garante largura de banda dedicada para o DoubleZero, é operacionalmente simples e assegura segmentação completa de quaisquer outros serviços de rede. Esta opção provavelmente terá o maior aumento de OPEX e requer novos contratos de serviço com operadoras de terceiros. @@ -121,23 +121,23 @@ Esta opção é atraente pois garante largura de banda dedicada para o DoubleZer ### Contribuição de Largura de Banda de 100Gbps -Observe que as quantidades abaixo refletem os equipamentos necessários em dois data centers, ou seja, o total de hardware necessário para implantar 1 cabo de fibra óptica para contribuição de largura de banda. +Observe que as quantidades abaixo refletem o equipamento necessário em dois data centers, ou seja, o total de hardware necessário para implantar 1 cabo de fibra óptica para contribuição de largura de banda. ??? warning "*Todos os FPGAs estão sujeitos a testes finais. Contribuições de 10G podem ser suportadas usando switches Arista 7130LBR com FPGAs Virtex® UltraScale+™ duplos integrados (se você tiver alguma dúvida, a DoubleZero Foundation / Malbec Labs terá prazer em fornecer mais informações)." #### Requisitos de Função e Portas -| Função | Velocidade da Porta | Requisito DZ | QTD | Nota | +| Função | Velocidade da Porta | Requisito DZ | QTD | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Largura de Banda Privada | 100G | Sim | 1 | | -| Acesso Direto à Internet (DIA) | 10G | Sim | 2 | | +| Private Bandwidth | 100G | Sim | 1 | | +| Direct Internet Access (DIA) | 10G | Sim | 2 | | | DoubleZero eXchange (DZX) | 100G | Sim* | 1 | Deve ser suportado quando mais de 3 provedores operam na mesma área metropolitana; antes disso, cross-connects ou outros arranjos de peering podem ser usados para interconectar com outros provedores. | -| Gerenciamento | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | -| Console | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | +| Gerenciamento | | Não | 1 | Determinado pelas políticas internas de gerenciamento do contribuidor. | +| Console | | Não | 1 | Determinado pelas políticas internas de gerenciamento do contribuidor. | #### Hardware de Rede DZD -| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | +| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | Sim | 4 | | | Arista | 7280CR3A | DCS-7280CR3A-32S | Sim | 2 | Alternativas podem ser possíveis se os prazos de entrega forem desafiadores. | @@ -146,48 +146,48 @@ Observe que as quantidades abaixo refletem os equipamentos necessários em dois #### Ópticas - 100G -| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | +| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 16 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. 100G necessário para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 16 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. 100G necessário para conectar FPGAs. | --- #### Ópticas - 10G -| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | +| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Não | 2 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | -| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 2 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | Não | 2 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | +| Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 2 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | --- #### Endereçamento IP -| Endereçamento IP | Tamanho Mínimo de Sub-rede | Requisito DZ | Nota | +| Endereçamento IP | Tamanho Mínimo da Sub-rede | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 Público | /29 | Sim (para DZDs edge/híbridos) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | +| Public IPv4 | /29 | Sim (para DZDs de borda/híbridos) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | Certifique-se de que o pool /29 completo esteja disponível para o protocolo DZ. Quaisquer requisitos de endereçamento ponto a ponto, por exemplo, em interfaces DIA, devem ser gerenciados por meio de um pool de endereços diferente. ### Contribuição de Largura de Banda de 10Gbps -Observe que as quantidades refletem os equipamentos de dois data centers, ou seja, o total de hardware necessário para implantar 1 contribuição de largura de banda. +Observe que as quantidades refletem o equipamento de dois data centers, ou seja, o total de hardware necessário para implantar 1 contribuição de largura de banda. #### Requisitos de Função e Portas -| Função | Velocidade da Porta | Requisito DZ | QTD | Nota | +| Função | Velocidade da Porta | Requisito DZ | QTD | Nota | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Largura de Banda Privada | 10G | Sim | 1 | | -| Acesso Direto à Internet (DIA) | 10G | Sim | 2 | | +| Private Bandwidth | 10G | Sim | 1 | | +| Direct Internet Access (DIA) | 10G | Sim | 2 | | | DoubleZero eXchange (DZX) | 100G | Sim* | 1 | Deve ser suportado quando mais de 3 provedores operam na mesma área metropolitana; antes disso, cross-connects ou outros arranjos de peering podem ser usados para interconectar com outros provedores. | -| Gerenciamento | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | -| Console | | Não | 1 | Determinado pelas políticas internas de gerenciamento do próprio contribuidor. | +| Gerenciamento | | Não | 1 | Determinado pelas políticas internas de gerenciamento do contribuidor. | +| Console | | Não | 1 | Determinado pelas políticas internas de gerenciamento do contribuidor. | --- #### Hardware -| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | +| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474* | Sim | 4 | | | | Arista | 7280CR3A | DCS-7280CR3A-32S | Sim | 2 | Alternativas podem ser possíveis se os prazos de entrega forem desafiadores. | @@ -196,25 +196,25 @@ Observe que as quantidades refletem os equipamentos de dois data centers, ou sej #### Ópticas - 100G -| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | +| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 14 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. 100G necessário para conectar FPGAs. | +| Arista | 100GBASE-LR | QSFP-100G-LR | Não | 14 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. 100G necessário para conectar FPGAs. | --- #### Ópticas - 10G -| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | +| Fabricante | Modelo | Número de Peça | Requisito DZ | QTD | Nota | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| -| Arista | 10GBASE-LR | SFP-10G-LR | Não | 4 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | - Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 4 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | +| Arista | 10GBASE-LR | SFP-10G-LR | Não | 4 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | + Finisar | DynamiX QSA™ | MAM1Q00A-QSA | Não | 4 | Cabeamento e escolha de óptica disponíveis a critério do contribuidor. | --- #### Endereçamento IP -| Endereçamento IP | Tamanho Mínimo de Sub-rede | Requisito DZ | Nota | +| Endereçamento IP | Tamanho Mínimo da Sub-rede | Requisito DZ | Nota | |--------------|-------------------|----------------|----------------------------------------------------------| -| IPv4 Público | /29 | Sim (para DZDs edge/híbridos) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | +| Public IPv4 | /29 | Sim (para DZDs de borda/híbridos) | Deve ser roteável via DIA. Podemos eliminar a necessidade disso ao longo do tempo. | Certifique-se de que o pool /29 completo esteja disponível para o protocolo DZ. Quaisquer requisitos de endereçamento ponto a ponto, por exemplo, em interfaces DIA, devem ser gerenciados por meio de um pool de endereços diferente. @@ -222,35 +222,35 @@ Certifique-se de que o pool /29 completo esteja disponível para o protocolo DZ. #### Requisitos de Rack e Energia -Os valores abaixo são **por DZD**, ou seja, por data center. Uma contribuição de largura de banda de 100G ou 10G coloca um DZD em cada extremidade do link, portanto planeje isso duas vezes. +Os valores abaixo são **por DZD**, portanto por data center. Uma contribuição de largura de banda de 100G ou 10G coloca um DZD em cada extremidade do link, então planeje isso duas vezes. ##### Espaço em rack | Item | Unidades de rack | Necessário | |------|-----------|--------| | Switch DZD (Arista 7280CR3A-32S ou 7130LBR) | 1U | Agora | -| Appliance de filtragem de borda | 1U | Posteriormente, apenas em dispositivos edge e híbridos | +| Appliance de filtragem de borda | 1U | Posteriormente, apenas em dispositivos de borda e híbridos | -**Reserve 2U por DZD.** Uma unidade está em uso hoje. Mantenha a segunda livre para que o appliance de filtragem de borda possa ser instalado ao lado do switch sem necessidade de remanejamento no rack. Deixe espaço para fluxo de ar e gerenciamento de cabos conforme sua instalação exigir. +**Reserve 2U por DZD.** Uma unidade está em uso hoje. Mantenha a segunda livre para que o appliance de filtragem de borda possa ser instalado próximo ao switch sem necessidade de remanejamento no rack. Deixe espaço para fluxo de ar e gerenciamento de cabos conforme sua instalação exigir. ##### Energia | Item | Consumo típico | |------|-------------| | Arista 7280CR3A-32S | ~300 W | -| Ópticas, por QSFP 100G | ~5 W | +| Ópticas, por 100G QSFP | ~5 W | -**Solicite 2 kW por DZD, divididos entre duas alimentações independentes.** Dimensione cada alimentação para suportar a carga total sozinha. O switch opera com fontes de alimentação redundantes e, após uma falha de alimentação, uma delas pode ser tudo o que resta. +**Solicite 2 kW por DZD, divididos em duas alimentações independentes.** Dimensione cada alimentação para suportar toda a carga sozinha. O switch possui fontes de alimentação redundantes e, após uma falha de alimentação, uma delas pode ser tudo o que resta. -2 kW é confortável em vez de justo. Um DZD apenas com switch, que é o que quase todas as implantações executam hoje, consome bem menos de 500 W com todas as suas ópticas ativas. O restante dos 2 kW é reservado para o appliance de filtragem de borda, que contém os FPGAs e será instalado posteriormente. +2 kW é confortável em vez de justo. Um DZD apenas com switch, que é o que quase toda implantação executa hoje, consome bem abaixo de 500 W com todas as suas ópticas acesas. O restante dos 2 kW é reservado para o appliance de filtragem de borda, que contém os FPGAs e será instalado posteriormente. !!! warning "Não solicite energia em excesso" - Você paga pela energia que reserva, independentemente de consumi-la ou não. Um DZD é uma única unidade de rack de switching, não um chassi de computação, portanto consome muito menos do que sua posição no rack poderia fornecer. Reservar mais de 2 kW por DZD significa pagar por capacidade que fica ociosa. + Você paga pela energia que reserva, independentemente de utilizá-la ou não. Um DZD é uma única unidade de rack de comutação, não um chassi de computação, portanto consome muito menos do que sua posição no rack poderia fornecer. Reservar mais de 2 kW por DZD significa pagar por capacidade que fica ociosa. !!! note "Verifique seu próprio hardware antes de fazer o pedido" - Estes são valores de referência de nossas próprias implantações. Seu consumo real depende da configuração da sua fonte de alimentação, de quantas portas você ativa e de quais ópticas você escolhe. Confirme com as especificações de potência da fonte de alimentação na folha de dados do fabricante para o hardware exato que você adquirir. + Estes são valores de referência de nossas próprias implantações. Seu consumo real depende da configuração da fonte de alimentação, quantas portas você ativa e quais ópticas você escolhe. Confirme com as especificações de potência da fonte de alimentação na ficha técnica do fabricante para o hardware exato que você comprar. - Também não reduza o pedido ao mínimo absoluto. A energia precisa estar disponível no rack, e adicionar uma alimentação posteriormente geralmente significa um novo pedido junto à instalação, o que pode levar semanas. + Também não reduza o pedido ao mínimo absoluto. A energia precisa estar disponível no rack, e adicionar uma alimentação posteriormente geralmente significa um novo pedido com a instalação, o que pode levar semanas. --- diff --git a/docs/contribute.zh.md b/docs/contribute.zh.md index be27e01..ce980b2 100644 --- a/docs/contribute.zh.md +++ b/docs/contribute.zh.md @@ -1,99 +1,99 @@ --- -description: 为 DoubleZero 网络贡献容量所需的硬件、带宽和连接要求及架构。 +description: 为 DoubleZero 网络贡献容量的硬件、带宽和连接要求及架构。 --- # 贡献者要求与架构 ## 概述 -任何希望将其未充分利用的光纤电缆和网络硬件进行变现的人都可以为 DoubleZero 网络做出贡献。网络贡献者必须在两个站点之间提供专用带宽，在每端运行 DoubleZero 兼容设备 (DZD)，并在每端提供公共互联网连接。网络贡献者还必须在每个 DZD 上运行 DoubleZero 软件，以提供组播、用户查找和边缘过滤等服务。 +任何希望将其未充分利用的光纤线缆和网络硬件进行变现的实体，都可以为 DoubleZero 网络做出贡献。网络贡献者必须在两个节点之间提供专用带宽，在每端运行 DoubleZero 兼容设备（DZD），并在每端提供公共互联网连接。网络贡献者还必须在每台 DZD 上运行 DoubleZero 软件，以提供组播、用户查找和边缘过滤等服务。 -DoubleZero 智能合约是确保网络维持高质量链路的基石，这些链路可以被测量并集成到拓扑结构中，使我们的网络控制器能够在不同用户和端点之间开发最高效的端到端路径。在智能合约执行以及网络设备和带宽部署完成后，实体即被归类为网络贡献者。请参阅 [DoubleZero Economics](https://economics.doublezero.xyz/overview) 以进一步了解作为网络贡献者参与 DoubleZero 的经济模型。 +DoubleZero 智能合约是确保网络维持高质量链路的基石，这些链路可以被测量并集成到拓扑中，使我们的网络控制器能够在不同用户和端点之间开发最高效的端到端路径。在执行智能合约并部署网络设备和带宽后，该实体即被归类为网络贡献者。请参阅 [DoubleZero Economics](https://economics.doublezero.xyz/overview) 以进一步了解作为网络贡献者参与 DoubleZero 的经济模型。 --- ## 成为 DoubleZero 网络贡献者的要求 - 能够在两个数据中心之间提供 IPv4 连接和 2048 字节 MTU 的专用带宽 -- 与 DoubleZero 协议兼容的 DoubleZero 设备 (DZD) 硬件 -- 与互联网和其他 DoubleZero 网络贡献者的连接 +- 与 DoubleZero 协议兼容的 DoubleZero 设备（DZD）硬件 +- 与互联网及其他 DoubleZero 网络贡献者的连接 - 在 DZD 上安装 DoubleZero 软件 ## 快速入门指南 -作为网络贡献者，开始参与 DoubleZero 最简单的方式是识别您网络中可以专用于 DoubleZero 的容量。一旦确定，必须部署 DZD，以促进 DoubleZero 叠加网络的建立——该网络仅要求贡献者网络提供 IPv4 可达性和最低 2048 字节的 MTU 作为依赖条件。 +作为网络贡献者，开始使用 DoubleZero 的最简单方式是识别您网络中可以专门用于 DoubleZero 的容量。一旦确定，必须部署 DZD，以促进 DoubleZero 覆盖网络的建立——该网络仅需要贡献者网络提供 IPv4 可达性和最低 2048 字节的 MTU 作为依赖条件。 -图 1 展示了贡献带宽和数据包发送与处理服务的最简模型。在每个数据中心部署一个 DZD，与网络贡献者的内部网络对接，以提供 DoubleZero WAN 连接。这通过本地互联网连接来补充，通常是直连互联网接入 (DIA) 解决方案，用作 DoubleZero 用户的接入点。虽然预计 DIA 将是为 DoubleZero 用户提供接入的首选方案，但也支持多种连接模型，例如到服务器的物理布线、网络架构扩展等。我们将这些选项称为自选冒险方案 (CYOA)，为贡献者提供灵活性，以最适合其内部网络策略的方式连接本地或远程用户。 +图 1 展示了贡献带宽和数据包发送与处理服务的最简单模型。每个数据中心部署一台 DZD，与网络贡献者的内部网络对接，提供 DoubleZero WAN 连接。这通过本地互联网（通常是专线互联网接入（DIA）解决方案）作为补充，用作 DoubleZero 用户的接入点。虽然预计 DIA 将是为 DoubleZero 用户提供接入的首选方案，但也支持多种连接模型，例如物理线缆直连服务器、网络结构扩展等。我们将这些选项称为自主选择方案（CYOA），为贡献者提供以最适合其内部网络策略的方式连接本地或远程用户的灵活性。 -与任何网络一样，可达性是架构的基本组成部分，因为网络贡献者不能孤立存在。因此，DZD *必须* 与 DoubleZero 交换节点 (DZX) 建立链路，以在参与者之间创建连续的网络。 +与任何网络一样，可达性是架构的基本组成部分，因为网络贡献者不能孤立存在。因此，DZD *必须*连接到 DoubleZero 交换中心（DZX），以在参与者之间创建连续的网络。
![Image title](images/figure1.png){ width="800" } -
图 1：2 个数据中心之间的 DoubleZero 网络带宽贡献 - 单个贡献者
+
图 1：DoubleZero 网络在 2 个数据中心之间的带宽贡献 - 单一贡献者
### 贡献示例 网络贡献者可以通过多种方式扩展其 DoubleZero 贡献，包括： -- 提升现有贡献的性能特征：增加带宽、降低延迟 +- 改善现有贡献的性能特征：增加带宽、降低延迟 - 在相同数据中心之间添加多条链路 - 从现有数据中心到新数据中心添加新链路 - 在两个新数据中心之间添加新的独立链路 -#### 示例 1：单个贡献者，3 个数据中心，两条链路 +#### 示例 1：单一贡献者，3 个数据中心，两条链路
![Image title](images/figure2.png){ width="800" } -
图 2：3 个数据中心之间的 DoubleZero 网络带宽贡献 - 单个贡献者
+
图 2：DoubleZero 网络在 3 个数据中心之间的带宽贡献 - 单一贡献者
-单个 DZD 可以支持向 DoubleZero 贡献的多条链路。图 2 展示了当单个数据中心（标记为 1）终结到两个不同远程数据中心 2 和 3 的带宽时的潜在拓扑结构。在此场景中，每个数据中心仅包含 1 个 DZD。所有 DZD 都使用 DIA 作为其 CYOA 接口的用户接入点。 +单台 DZD 可以支持为 DoubleZero 贡献的多条链路。图 2 展示了当单个数据中心（标记为 1）将带宽终结到两个不同的远程数据中心 2 和 3 时的潜在拓扑。在此场景中，每个数据中心仅包含 1 台 DZD。所有 DZD 均使用 DIA 作为用户接入的 CYOA 接口。 -#### 示例 2：单个贡献者，3 个数据中心，三条链路 +#### 示例 2：单一贡献者，3 个数据中心，三条链路 -图 3 描述了当单个贡献者在 3 个数据中心之间以三角形拓扑部署三条链路时的 DoubleZero 拓扑结构。在与示例 1 类似的场景中，数据中心 1、2 和 3 各部署一个 DZD，每个支持 2 条独立的网络链路。最终拓扑为数据中心之间的三角形或环形结构。 +图 3 描述了当单一贡献者在 3 个数据中心之间以三角形拓扑部署三条链路时的 DoubleZero 拓扑。在与示例 1 类似的场景中，数据中心 1、2 和 3 各部署一台 DZD，每台支持 2 条独立的网络链路。由此形成的拓扑是数据中心之间的三角形或环形。
![Image title](images/figure3.png){ width="800" } -
图 3：3 个数据中心之间的 DoubleZero 网络带宽贡献 - 单个贡献者
+
图 3：DoubleZero 网络在 3 个数据中心之间的带宽贡献 - 单一贡献者
-### DoubleZero 交换节点 +### DoubleZero 交换中心 -创建连续网络是 DoubleZero 架构的基本构建模块。贡献者通过都会区域内的 DoubleZero 交换节点 (DZX) 进行互联，都会区域即一个城市，如纽约 (NYC)、伦敦 (LON) 或东京 (TYO)。DZX 是类似于互联网交换中心的网络架构，允许对等互联和路由交换。 +创建连续网络是 DoubleZero 架构的基本构建模块。贡献者通过都会区内的 DoubleZero 交换中心（DZX）进行互联，都会区即纽约（NYC）、伦敦（LON）或东京（TYO）等城市。DZX 是类似于互联网交换中心的网络交换结构，允许对等互联和路由交换。 在图 4 中，网络贡献者 1 在数据中心 1、2 和 3 中运营，而网络贡献者 2 在数据中心 2、4 和 5 中运营。通过在数据中心 2 互联，DoubleZero 网络覆盖范围扩展到 5 个连续的数据中心。
![Image title](images/figure4.png){ width="1000" } -
图 4：2 个网络带宽贡献者之间的 DoubleZero 网络带宽贡献
+
图 4：两个网络带宽贡献者之间的 DoubleZero 网络带宽贡献
### 带宽贡献选项 -DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心的 DZD 之间提供具有保证带宽、延迟和抖动配置的集成连接。DoubleZero 不强制规定网络贡献者如何实施其贡献，但在以下部分我们提供了指导性选项，供其自行决定使用。 +DoubleZero 要求网络贡献者通过智能合约提供两个终端数据中心 DZD 之间的集成连接，包括保证的带宽、延迟和抖动配置。DoubleZero 不强制规定网络贡献者如何实施其贡献，但在以下章节中，我们提供了供其自行决定使用的参考方案。 -网络贡献者需要考虑的重要方面可能包括： +网络贡献者可能需要考虑的重要方面包括： - 保证 DoubleZero 服务网络性能的能力：带宽、延迟和抖动 -- 与现有内部网络服务的隔离 +- 与其现有内部网络服务的隔离 - IPv4 地址冲突，特别是与隧道底层地址空间的冲突 - 正常运行时间和可用性 -- 资本支出 (CAPEX) 和运营支出 (OPEX) 考量 +- 资本支出和运营支出考量 #### 第 1 层带宽
![Image title](images/figure5.png){ width="800" } -
图 5：第 1 层光学服务
+
图 5：第 1 层光纤服务
-第 1 层带宽，更正式地称为波长服务，可以在现有光学基础设施上配置专用容量，例如 DWDM、CWDM 或通过光复用器 (MUX)。在图 5 中，DZD 使用彩色光模块连接到 L1 MUX，将 DZD 波长交织到现有暗光纤上。 +第 1 层带宽，更正式的说法是波长服务，可以在现有光纤基础设施上配置专用容量，例如 DWDM、CWDM 或通过光复用器（MUX）。在图 5 中，DZD 使用彩色光模块，通过线缆连接到 L1 MUX，将 DZD 波长交织到现有暗光纤上。 -该解决方案对于已经运营现有核心网络的网络贡献者具有诸多优势。增量运营变更以及额外的 CAPEX 和 OPEX 要求都相对适中。此选项在提供与网络贡献者网络服务的隔离方面尤为稳健。 +对于已经运营现有核心网络的网络贡献者来说，该解决方案具有众多优势。增量运营变更以及额外的资本支出和运营支出要求都很适度。该选项在提供与网络贡献者网络服务隔离方面尤其稳健。 #### 分组交换带宽 -分组交换网络可以被视为典型的企业网络，运行标准路由和交换协议以支持业务应用。有多种网络技术可以实现连接，例如使用 VLAN 标签的第 2 层 (L2) 扩展。 +分组交换网络可以被视为典型的企业网络，运行支持业务应用的标准路由和交换协议。有许多网络技术可以实现连接，例如使用 VLAN 标签的第 2 层（L2）扩展。 ##### L2 扩展
@@ -101,9 +101,9 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心
图 6：分组交换网络 - L2 扩展
-如图 6 所示，L2 扩展可以通过 VLAN 标记来实现。DZD 的端口可以连接到贡献者的内部网络交换机，交换机端口设置为接入端口，例如在 VLAN 10 中。通过 802.1q 标记，该 VLAN 可以在贡献者网络上跨越多个交换机跳数传输，终止于与远程 DZD 对接的交换机。 +如图 6 所示的 L2 扩展可以通过 VLAN 标签来实现。DZD 的端口可以通过线缆连接到贡献者的内部网络交换机，交换机端口设置为 access 端口，例如 VLAN 10。通过 802.1q 标签，该 VLAN 可以在贡献者网络上跨多个交换机跳数承载，终结于与远程 DZD 对接的交换机。 -该解决方案的优势在于广泛支持且相对容易实施，同时在 DoubleZero 和内部第 3 层服务之间创建了分段隔离。带宽可以基于贡献者内部交换机或路由器的接口速度进行控制。需要仔细考虑通过服务质量 (QoS) 或其他流量管理策略在共享内部 L2 网络上的性能表现。但是，如果贡献者核心网络中有可用容量，额外的 CAPEX 和 OPEX 投入应该是适中的。 +该解决方案受益于广泛的支持和相对简便的实施，同时在 DoubleZero 和内部第 3 层服务之间创建了隔离。带宽可以根据贡献者内部交换机或路由器的接口速度进行控制。必须通过服务质量（QoS）或其他流量管理策略等技术，仔细考虑共享内部 L2 网络上的性能。然而，如果贡献者核心网络中存在可用容量，额外的资本支出和运营支出投入应该是适度的。 #### 专用第三方带宽
@@ -111,9 +111,9 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心
图 7：专用第三方带宽
-虽然重用可用容量对许多网络贡献者来说很有吸引力，但也可以将新采购的带宽专用于 DoubleZero。在这种情况下，DZD 将直接连接到第三方运营商，贡献者的内部设备不在链路中（图 7）。 +虽然复用可用容量对许多网络贡献者具有吸引力，但也可以将新购置的带宽专门用于 DoubleZero。在这种情况下，DZD 将直接连接到第三方运营商，贡献者不会有任何内部设备串联在中间（图 7）。 -此选项的优势在于确保 DoubleZero 的专用带宽，操作简单且确保与其他网络服务完全隔离。此选项可能带来最高的 OPEX 增长，并且需要与第三方运营商签订新的服务合同。 +该选项的优势在于确保了 DoubleZero 的专用带宽，操作简单，并确保与任何其他网络服务完全隔离。该选项可能会导致最高的运营支出增加，并需要与第三方运营商签订新的服务合同。 --- @@ -121,32 +121,32 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心 ### 100Gbps 带宽贡献 -请注意，以下数量反映的是两个数据中心所需的设备，即部署 1 条光纤用于带宽贡献所需的全部硬件。 +请注意，以下数量反映的是两个数据中心所需的设备，即部署 1 条光纤线缆进行带宽贡献所需的全部硬件。 -??? warning "*所有 FPGA 均须经过最终测试。10G 贡献可能支持使用内置双 Virtex® UltraScale+™ FPGA 的 Arista 7130LBR 交换机（如有任何疑问，DoubleZero Foundation / Malbec Labs 很乐意提供更多信息）。*" +??? warning "*所有 FPGA 均需通过最终测试。10G 贡献可能支持使用内置双 Virtex® UltraScale+™ FPGA 的 Arista 7130LBR 交换机（如有任何问题，DoubleZero Foundation / Malbec Labs 很乐意提供更多信息）。" #### 功能与端口要求 -| 功能 | 端口速度 | DZ 要求 | 数量 | 备注 | +| 功能 | 端口速率 | DZ 要求 | 数量 | 备注 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 专用带宽 | 100G | 是 | 1 | | -| 直连互联网接入 (DIA) | 10G | 是 | 2 | | -| DoubleZero 交换节点 (DZX) | 100G | 是* | 1 | 当同一都会区域有超过 3 个提供商运营时必须支持，在此之前可以使用交叉连接或其他对等互联安排与其他提供商互联。 | -| 管理 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | -| 控制台 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | +| 专线互联网接入（DIA） | 10G | 是 | 2 | | +| DoubleZero 交换中心（DZX） | 100G | 是* | 1 | 当同一都会区有超过 3 个提供商运营时必须支持，在此之前可以使用交叉连接或其他对等互联安排与其他提供商互联。 | +| 管理 | | 否 | 1 | 由贡献者自身内部管理策略决定。 | +| 控制台 | | 否 | 1 | 由贡献者自身内部管理策略决定。 | #### DZD 网络硬件 -| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | +| 制造商 | 型号 | 产品编号 | DZ 要求 | 数量 | 备注 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474 | 是 | 4 | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如果交货周期紧张，可能有替代方案。 | +| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如交货周期紧张，可能有替代方案。 | --- #### 光模块 - 100G -| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | +| 制造商 | 型号 | 产品编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| | Arista | 100GBASE-LR | QSFP-100G-LR | 否 | 16 | 布线和光模块选择由贡献者自行决定。连接 FPGA 需要 100G。 | @@ -154,7 +154,7 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心 #### 光模块 - 10G -| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | +| 制造商 | 型号 | 产品编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| | Arista | 10GBASE-LR | SFP-10G-LR | 否 | 2 | 布线和光模块选择由贡献者自行决定。 | | Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 否 | 2 | 布线和光模块选择由贡献者自行决定。 | @@ -165,9 +165,9 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心 | IP 地址 | 最小子网大小 | DZ 要求 | 备注 | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | 是（用于边缘/混合 DZD） | 必须可通过 DIA 路由。我们可能会在未来逐步取消此要求。 | +| Public IPv4 | /29 | 是（适用于边缘/混合 DZD） | 必须可通过 DIA 路由。我们可能会随时间推移消除此需求。 | -请确保完整的 /29 地址池可用于 DZ 协议。任何点对点地址需求（例如 DIA 接口上的地址）应通过不同的地址池进行管理。 +请确保完整的 /29 地址池可用于 DZ 协议。任何点对点寻址需求（例如 DIA 接口上的地址）应通过不同的地址池进行管理。 ### 10Gbps 带宽贡献 @@ -175,28 +175,28 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心 #### 功能与端口要求 -| 功能 | 端口速度 | DZ 要求 | 数量 | 备注 | +| 功能 | 端口速率 | DZ 要求 | 数量 | 备注 | |-----------------------------|------------|----------------|-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 专用带宽 | 10G | 是 | 1 | | -| 直连互联网接入 (DIA) | 10G | 是 | 2 | | -| DoubleZero 交换节点 (DZX) | 100G | 是* | 1 | 当同一都会区域有超过 3 个提供商运营时必须支持；在此之前可以使用交叉连接或其他对等互联安排与其他提供商互联。 | -| 管理 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | -| 控制台 | | 否 | 1 | 由贡献者自身的内部管理策略决定。 | +| 专线互联网接入（DIA） | 10G | 是 | 2 | | +| DoubleZero 交换中心（DZX） | 100G | 是* | 1 | 当同一都会区有超过 3 个提供商运营时必须支持；在此之前可以使用交叉连接或其他对等互联安排与其他提供商互联。 | +| 管理 | | 否 | 1 | 由贡献者自身内部管理策略决定。 | +| 控制台 | | 否 | 1 | 由贡献者自身内部管理策略决定。 | --- #### 硬件 -| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | +| 制造商 | 型号 | 产品编号 | DZ 要求 | 数量 | 备注 | |----------|-----------------|----------------------|----------------|-----|-----------------------------------------------------------| | AMD* | V80* | 24540474* | 是 | 4 | | | -| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如果交货周期紧张，可能有替代方案。 | +| Arista | 7280CR3A | DCS-7280CR3A-32S | 是 | 2 | 如交货周期紧张，可能有替代方案。 | --- #### 光模块 - 100G -| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | +| 制造商 | 型号 | 产品编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| | Arista | 100GBASE-LR | QSFP-100G-LR | 否 | 14 | 布线和光模块选择由贡献者自行决定。连接 FPGA 需要 100G。 | @@ -204,7 +204,7 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心 #### 光模块 - 10G -| 制造商 | 型号 | 零件编号 | DZ 要求 | 数量 | 备注 | +| 制造商 | 型号 | 产品编号 | DZ 要求 | 数量 | 备注 | |--------|-------------|----------------|----------------|-----|-------------------------------------------------------------| | Arista | 10GBASE-LR | SFP-10G-LR | 否 | 4 | 布线和光模块选择由贡献者自行决定。 | Finisar | DynamiX QSA™ | MAM1Q00A-QSA | 否 | 4 | 布线和光模块选择由贡献者自行决定。 | @@ -214,24 +214,24 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心 | IP 地址 | 最小子网大小 | DZ 要求 | 备注 | |--------------|-------------------|----------------|----------------------------------------------------------| -| Public IPv4 | /29 | 是（用于边缘/混合 DZD） | 必须可通过 DIA 路由。我们可能会在未来逐步取消此要求。 | +| Public IPv4 | /29 | 是（适用于边缘/混合 DZD） | 必须可通过 DIA 路由。我们可能会随时间推移消除此需求。 | -请确保完整的 /29 地址池可用于 DZ 协议。任何点对点地址需求（例如 DIA 接口上的地址）应通过不同的地址池进行管理。 +请确保完整的 /29 地址池可用于 DZ 协议。任何点对点寻址需求（例如 DIA 接口上的地址）应通过不同的地址池进行管理。 ### 数据中心要求 -#### 机柜与电力要求 +#### 机架与电力要求 -以下数据为**每个 DZD** 的数据，即每个数据中心的数据。100G 或 10G 带宽贡献在链路每端各放置一个 DZD，因此请按两倍规划。 +以下数据为**每台 DZD**，即每个数据中心的需求。100G 或 10G 带宽贡献在链路的每端各放置一台 DZD，因此请按两倍规划。 -##### 机柜空间 +##### 机架空间 | 项目 | 机架单元 | 需求时间 | |------|-----------|--------| -| DZD 交换机 (Arista 7280CR3A-32S 或 7130LBR) | 1U | 现在 | +| DZD 交换机（Arista 7280CR3A-32S 或 7130LBR） | 1U | 当前 | | 边缘过滤设备 | 1U | 后续，仅适用于边缘和混合设备 | -**每个 DZD 预留 2U。** 其中一个单元目前在使用中。保留第二个空位，以便边缘过滤设备日后可以安装在交换机旁边，无需进行机柜迁移。根据您的设施要求预留气流和线缆管理空间。 +**每台 DZD 预留 2U。** 目前使用一个单元。保留第二个空闲，以便边缘过滤设备可以安装在交换机旁边而无需移动机架。根据您设施的要求留出气流和线缆管理空间。 ##### 电力 @@ -240,20 +240,20 @@ DoubleZero 要求网络贡献者通过智能合约，在两个终端数据中心 | Arista 7280CR3A-32S | ~300 W | | 光模块，每个 100G QSFP | ~5 W | -**每个 DZD 订购 2 kW，分配到两路独立电源。** 每路电源的容量应能独立承载全部负载。交换机配备冗余电源，在一路电源故障后，您可能只剩下其中一个电源模块可用。 +**每台 DZD 订购 2 kW，分配到两路独立电源。** 每路电源的容量应能独立承载全部负载。交换机配备冗余电源，当一路电源故障后，您可能只剩下其中一个电源模块。 -2 kW 是留有余量而非紧凑的配置。仅交换机的 DZD（这是目前绝大多数部署的配置），在所有光模块点亮后功耗远低于 500 W。其余 2 kW 容量是为边缘过滤设备预留的，该设备包含 FPGA 并将在后续安装。 +2 kW 是留有余量而非紧凑的配置。仅包含交换机的 DZD（这是目前几乎所有部署的情况），在所有光模块点亮的情况下功耗远低于 500 W。其余的 2 kW 是为边缘过滤设备预留的，该设备包含 FPGA，将在后续安装。 !!! warning "不要过度订购电力" - 无论是否实际使用，您都需要为预留的电力付费。DZD 是单个机架单元的交换设备，不是计算机箱，因此其功耗远低于该机架位置所能供应的电力。每个 DZD 预留超过 2 kW 意味着为闲置容量付费。 + 无论是否实际使用，您都需要为预留的电力付费。DZD 是单个机架单元的交换设备，而非计算机箱，因此其功耗远低于其机架位置所能提供的电力。每台 DZD 预留超过 2 kW 意味着为闲置容量付费。 -!!! note "下单前请核实您自己的硬件" - 这些是我们自身部署的指导性数据。您的实际功耗取决于您的电源配置、点亮的端口数量以及选择的光模块。请根据您购买的具体硬件的供应商数据表中的电源额定值进行确认。 +!!! note "订购前请确认您的实际硬件参数" + 这些是我们自身部署的参考数据。您的实际功耗取决于电源配置、点亮的端口数量以及所选的光模块。请根据您实际购买硬件的供应商数据手册中的电源额定值进行确认。 - 也不要将订单削减到最低限度。电力必须在机柜中可用，而后续增加电源通常意味着向数据中心提交新订单，这可能需要数周时间。 + 也不要将订购量削减到最低限度。电力必须在机架中可用，后续增加电源线路通常意味着向设施方提交新订单，这可能需要数周时间。 --- ## 后续步骤 -准备好配置您的第一个 DZD 了吗？请继续阅读 [设备配置指南](contribute-provisioning.md)。 \ No newline at end of file +准备好配置您的第一台 DZD 了吗？请继续阅读[设备配置指南](contribute-provisioning.md)。 \ No newline at end of file diff --git a/docs/glossary.es.md b/docs/glossary.es.md index d70c3d6..63e572a 100644 --- a/docs/glossary.es.md +++ b/docs/glossary.es.md @@ -14,16 +14,16 @@ Esta página define la terminología específica de DoubleZero utilizada a lo la El hardware físico de conmutación de red que termina los enlaces de DoubleZero y ejecuta el software DoubleZero Agent. Los DZDs se despliegan en centros de datos y proporcionan servicios de enrutamiento, procesamiento de paquetes y conectividad de usuarios. Cada DZD requiere [especificaciones de hardware](contribute.md#dzd-network-hardware) específicas y ejecuta tanto el [Config Agent](#config-agent) como el [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Puntos de interconexión en la red mallada donde se interconectan enlaces de diferentes [contribuidores](#contributor). Los DZXs están ubicados en las principales áreas metropolitanas (por ejemplo, NYC, LON, TYO) donde ocurren intersecciones de red. Los contribuidores de red deben interconectar sus enlaces en la malla más amplia de DoubleZero en el DZX más cercano. Similar en concepto a un Internet Exchange (IX). +Puntos de interconexión en la red mallada donde se conectan los enlaces de diferentes [contribuidores](#contributor). Los DZX están ubicados en las principales áreas metropolitanas (p. ej., NYC, LON, TYO) donde se producen intersecciones de red. Los contribuidores de red deben realizar la conexión cruzada de sus enlaces hacia la malla más amplia de DoubleZero en el DZX más cercano. Similar en concepto a un punto de intercambio de Internet (IX). ### WAN Link -Un enlace de Red de Área Amplia (Wide Area Network) entre dos [DZDs](#dzd-doublezero-device) operados por el **mismo** contribuidor. Los enlaces WAN proporcionan conectividad troncal dentro de la infraestructura de un único contribuidor. +Un enlace de Red de Área Amplia entre dos [DZDs](#dzd-doublezero-device) operados por el **mismo** contribuidor. Los enlaces WAN proporcionan conectividad troncal dentro de la infraestructura de un único contribuidor. ### DZX Link -Un enlace entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, establecido en un [DZX](#dzx-doublezero-exchange). Los enlaces DZX requieren aceptación explícita por ambas partes. +Un enlace entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, establecido en un [DZX](#dzx-doublezero-exchange). Los enlaces DZX requieren la aceptación explícita de ambas partes. ### DZ Prefix -Asignaciones de direcciones IP en formato CIDR asignadas a un [DZD](#dzd-doublezero-device) para el direccionamiento de la red overlay. Se especifican durante la [creación del dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando el parámetro `--dz-prefixes`. +Asignaciones de direcciones IP en formato CIDR asignadas a un [DZD](#dzd-doublezero-device) para el direccionamiento de la red superpuesta. Se especifican durante la [creación del dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando el parámetro `--dz-prefixes`. --- @@ -33,55 +33,55 @@ Asignaciones de direcciones IP en formato CIDR asignadas a un [DZD](#dzd-doublez Un [DZD](#dzd-doublezero-device) que proporciona conectividad de usuarios a la red DoubleZero. Los dispositivos edge aprovechan las interfaces [CYOA](#cyoa-choose-your-own-adventure) para terminar usuarios (validadores, operadores RPC) y conectarlos a la red. ### Transit Device -Un [DZD](#dzd-doublezero-device) que proporciona conectividad troncal dentro de la red DoubleZero. Los dispositivos transit mueven tráfico entre DZDs pero no terminan conexiones de usuarios directamente. +Un [DZD](#dzd-doublezero-device) que proporciona conectividad troncal dentro de la red DoubleZero. Los dispositivos de tránsito mueven tráfico entre DZDs pero no terminan conexiones de usuarios directamente. ### Hybrid Device -Un [DZD](#dzd-doublezero-device) que combina la funcionalidad tanto de [edge](#edge-device) como de [transit](#transit-device), proporcionando tanto conectividad de usuarios como enrutamiento troncal. +Un [DZD](#dzd-doublezero-device) que combina la funcionalidad tanto de [edge](#edge-device) como de [tránsito](#transit-device), proporcionando conectividad de usuarios y enrutamiento troncal. --- ## Conectividad ### CYOA (Choose Your Own Adventure) -Tipos de interfaces que permiten a los [contribuidores](#contributor) registrar opciones de conectividad para que los usuarios se conecten a la red DoubleZero. Las interfaces CYOA incluyen varios métodos como [DIA](#dia-direct-internet-access), túneles GRE y peering privado. Consulte [Creación de Interfaces CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) para detalles de configuración. +Tipos de interfaz que permiten a los [contribuidores](#contributor) registrar opciones de conectividad para que los usuarios se conecten a la red DoubleZero. Las interfaces CYOA incluyen varios métodos como [DIA](#dia-direct-internet-access), túneles GRE y peering privado. Consulte [Creación de Interfaces CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) para detalles de configuración. ### DIA (Direct Internet Access) Un término estándar de redes para la conectividad proporcionada a través de internet público. En DoubleZero, DIA es un tipo de interfaz [CYOA](#cyoa-choose-your-own-adventure) donde los usuarios (validadores, operadores RPC) se conectan a un [DZD](#dzd-doublezero-device) a través de su conexión a internet existente. ### IBRL (Increase Bandwidth Reduce Latency) -Un modo de conexión que permite a los validadores y nodos RPC conectarse a DoubleZero sin reiniciar sus clientes de blockchain. IBRL utiliza la dirección IP pública existente y establece un túnel overlay hacia el [DZD](#dzd-doublezero-device) más cercano. Consulte [Conexión Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instrucciones de configuración. +Un modo de conexión que permite a los validadores y nodos RPC conectarse a DoubleZero sin reiniciar sus clientes de blockchain. IBRL utiliza la dirección IP pública existente y establece un túnel superpuesto hacia el [DZD](#dzd-doublezero-device) más cercano. Consulte [Conexión Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instrucciones de configuración. ### Multicast -Un método de entrega de paquetes de uno a muchos soportado por DoubleZero. El modo multicast tiene dos roles: **publisher** (envía paquetes a través de la red) y **subscriber** (recibe paquetes del publisher). Utilizado por equipos de desarrollo para la distribución eficiente de datos. Consulte [Otra Conexión Multicast](Other%20Multicast%20Connection.md) para detalles de conexión. +Un método de entrega de paquetes de uno a muchos soportado por DoubleZero. El modo multicast tiene dos roles: **publicador** (envía paquetes a través de la red) y **suscriptor** (recibe paquetes del publicador). Utilizado por equipos de desarrollo para la distribución eficiente de datos. Consulte [Otra Conexión Multicast](Other%20Multicast%20Connection.md) para detalles de conexión. --- ## Componentes de Software ### doublezerod -El servicio daemon de DoubleZero que se ejecuta en los servidores de los usuarios (validadores, nodos RPC). Gestiona la conexión a la red DoubleZero, maneja el establecimiento de túneles y mantiene la conectividad con los [DZDs](#dzd-doublezero-device). Se configura mediante systemd y se controla a través del CLI [`doublezero`](#doublezero-cli). +El servicio daemon de DoubleZero que se ejecuta en los servidores de los usuarios (validadores, nodos RPC). Gestiona la conexión a la red DoubleZero, maneja el establecimiento de túneles y mantiene la conectividad con los [DZDs](#dzd-doublezero-device). Se configura a través de systemd y se controla mediante la CLI [`doublezero`](#doublezero-cli). ### doublezero (CLI) -La interfaz de línea de comandos para interactuar con la red DoubleZero. Se utiliza para conectarse, gestionar identidades, verificar el estado y operaciones administrativas. Se comunica con el daemon [`doublezerod`](#doublezerod). +La interfaz de línea de comandos para interactuar con la red DoubleZero. Se utiliza para conectarse, gestionar identidades, verificar el estado y realizar operaciones administrativas. Se comunica con el daemon [`doublezerod`](#doublezerod). ### Config Agent Agente de software que se ejecuta en los [DZDs](#dzd-doublezero-device) y gestiona la configuración del dispositivo. Lee la configuración del servicio [Controller](#controller) y aplica los cambios al dispositivo. Consulte [Instalación del Config Agent](contribute-provisioning.md#step-44-install-config-agent) para la configuración. ### Telemetry Agent -Agente de software que se ejecuta en los [DZDs](#dzd-doublezero-device) y recopila métricas de rendimiento (latencia, jitter, pérdida de paquetes) y las envía al ledger de DoubleZero. Consulte [Instalación del Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) para la configuración. +Agente de software que se ejecuta en los [DZDs](#dzd-doublezero-device) y recopila métricas de rendimiento (latencia, jitter, pérdida de paquetes) y las envía al libro mayor de DoubleZero. Consulte [Instalación del Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) para la configuración. ### Controller -Un servicio que proporciona configuración a los agentes de los [DZDs](#dzd-doublezero-device). El Controller deriva las configuraciones de los dispositivos a partir del estado [onchain](#onchain) en el ledger de DoubleZero. +Un servicio que proporciona configuración a los agentes de los [DZD](#dzd-doublezero-device). El Controller deriva las configuraciones de los dispositivos a partir del estado [onchain](#onchain) en el libro mayor de DoubleZero. --- ## Estados de los Enlaces ### Activated -El estado operativo normal para un enlace. El tráfico fluye a través del enlace y participa en las decisiones de enrutamiento. +El estado operativo normal de un enlace. El tráfico fluye a través del enlace y participa en las decisiones de enrutamiento. ### Soft-Drained -Un estado de mantenimiento donde se desaconseja el tráfico en un enlace específico. Se utiliza para ventanas de mantenimiento con transición gradual. Puede transicionar a [activated](#activated) o [hard-drained](#hard-drained). +Un estado de mantenimiento donde se desalienta el tráfico en un enlace específico. Se utiliza para ventanas de mantenimiento con transición gradual. Puede transicionar a [activated](#activated) o [hard-drained](#hard-drained). ### Hard-Drained Un estado de mantenimiento donde el enlace se retira completamente del servicio. No fluye tráfico a través del enlace. Debe transicionar a [soft-drained](#soft-drained) antes de volver a [activated](#activated). @@ -91,10 +91,10 @@ Un estado de mantenimiento donde el enlace se retira completamente del servicio. ## Organizaciones y Tokens ### DZF (DoubleZero Foundation) -DoubleZero Foundation es una empresa fundacional sin miembros y sin fines de lucro de las Islas Caimán que fue constituida para apoyar el desarrollo, la descentralización, la seguridad y la adopción de la red DoubleZero. +DoubleZero Foundation es una empresa fundacional sin miembros y sin fines de lucro de las Islas Caimán que fue creada para apoyar el desarrollo, la descentralización, la seguridad y la adopción de la red DoubleZero. ### 2Z Token -El token nativo de la red DoubleZero. Se utiliza para pagar las tarifas de los validadores y se distribuye como recompensas a los [contribuidores](#contributor). Los validadores pueden pagar las tarifas en 2Z a través de un programa de intercambio onchain. Consulte [Intercambio de SOL a 2Z](Swapping-sol-to-2z.md). +El token nativo de la red DoubleZero. Se utiliza para pagar las tarifas de validadores y se distribuye como recompensas a los [contribuidores](#contributor). Los validadores pueden pagar tarifas en 2Z a través de un programa de intercambio onchain. Consulte [Intercambio de SOL a 2Z](Swapping-sol-to-2z.md). ### Contributor Un proveedor de infraestructura de red que contribuye ancho de banda y hardware a la red DoubleZero. Los contribuidores operan [DZDs](#dzd-doublezero-device), proporcionan enlaces [WAN](#wan-link) y [DZX](#dzx-link), y reciben incentivos en tokens [2Z](#2z-token) por su contribución. Consulte la [Documentación para Contribuidores](contribute-overview.md) para comenzar. @@ -104,13 +104,13 @@ Un proveedor de infraestructura de red que contribuye ancho de banda y hardware ## Conceptos de Redes ### MTU (Maximum Transmission Unit) -El tamaño máximo de paquete (en bytes) que puede transmitirse a través de un enlace de red. Los enlaces WAN de DoubleZero típicamente utilizan MTU 9000 (jumbo frames) para mayor eficiencia. +El tamaño máximo de paquete (en bytes) que puede transmitirse a través de un enlace de red. Los enlaces WAN de DoubleZero típicamente utilizan MTU 9000 (tramas jumbo) para mayor eficiencia. ### VRF (Virtual Routing and Forwarding) -Una tecnología que permite que múltiples tablas de enrutamiento aisladas existan en el mismo router físico. Los contribuidores frecuentemente utilizan un VRF de gestión separado para aislar el tráfico de administración del switch del tráfico de producción. +Una tecnología que permite que múltiples tablas de enrutamiento aisladas existan en el mismo router físico. Los contribuidores a menudo utilizan un VRF de gestión separado para aislar el tráfico de gestión del switch del tráfico de producción. ### GRE (Generic Routing Encapsulation) -Un protocolo de tunelización que encapsula paquetes de red dentro de paquetes IP. Utilizado por las conexiones [IBRL](#ibrl-increase-bandwidth-reduce-latency) y [CYOA](#cyoa-choose-your-own-adventure) para crear túneles overlay entre usuarios y DZDs. +Un protocolo de tunelización que encapsula paquetes de red dentro de paquetes IP. Utilizado por las conexiones [IBRL](#ibrl-increase-bandwidth-reduce-latency) y [CYOA](#cyoa-choose-your-own-adventure) para crear túneles superpuestos entre usuarios y DZDs. ### BGP (Border Gateway Protocol) El protocolo de enrutamiento utilizado para intercambiar información de enrutamiento entre redes en internet. DoubleZero utiliza BGP internamente con ASN 65342. @@ -119,51 +119,51 @@ El protocolo de enrutamiento utilizado para intercambiar información de enrutam Un identificador único asignado a una red para el enrutamiento BGP. Todos los dispositivos DoubleZero utilizan **ASN 65342** para el proceso BGP interno. ### Loopback Interface -Una interfaz de red virtual en un router/switch utilizada con fines de gestión y enrutamiento. Los DZDs utilizan Loopback255 (VPNv4) y Loopback256 (IPv4) para el enrutamiento interno. +Una interfaz de red virtual en un router/switch utilizada para fines de gestión y enrutamiento. Los DZDs utilizan Loopback255 (VPNv4) y Loopback256 (IPv4) para el enrutamiento interno. ### CIDR (Classless Inter-Domain Routing) -Una notación para especificar rangos de direcciones IP. El formato es `IP/longitud-de-prefijo` donde la longitud del prefijo indica el tamaño de la red (por ejemplo, `/29` = 8 direcciones, `/24` = 256 direcciones). +Una notación para especificar rangos de direcciones IP. El formato es `IP/longitud-de-prefijo` donde la longitud del prefijo indica el tamaño de la red (p. ej., `/29` = 8 direcciones, `/24` = 256 direcciones). ### Jitter Variación en la latencia de los paquetes a lo largo del tiempo. Un jitter bajo es crítico para aplicaciones en tiempo real. ### RTT (Round-Trip Time) -El tiempo que tarda un paquete en viajar desde el origen hasta el destino y de vuelta. Se utiliza para medir la latencia de red entre dispositivos. +El tiempo que tarda un paquete en viajar desde el origen al destino y regresar. Se utiliza para medir la latencia de red entre dispositivos. ### TWAMP (Two-Way Active Measurement Protocol) Un protocolo para medir métricas de rendimiento de red como latencia y pérdida de paquetes. El [Telemetry Agent](#telemetry-agent) utiliza TWAMP para recopilar métricas entre DZDs. ### IS-IS (Intermediate System to Intermediate System) -Un protocolo de enrutamiento de estado de enlace utilizado internamente por la red DoubleZero. Las métricas de IS-IS se ajustan durante las operaciones de [drenado de enlaces](#soft-drained). +Un protocolo de enrutamiento de estado de enlace utilizado internamente por la red DoubleZero. Las métricas de IS-IS se ajustan durante las operaciones de [drenaje de enlaces](#soft-drained). --- ## Geolocalización ### Geolocation -Un servicio de DoubleZero que verifica la ubicación física de los dispositivos utilizando mediciones de latencia. Las mediciones de [RTT](#rtt-round-trip-time) entre infraestructura de ubicación conocida ([DZDs](#dzd-doublezero-device)) y dispositivos objetivo proporcionan una prueba firmada criptográficamente de que un dispositivo se encuentra dentro de una cierta distancia de un punto de referencia. El registro onchain de las mediciones está planificado para una versión futura. Consulte [Geolocalización](geolocation.md) para la documentación de usuario. +Un servicio de DoubleZero que verifica la ubicación física de los dispositivos mediante mediciones de latencia. Las mediciones de [RTT](#rtt-round-trip-time) entre infraestructura de ubicación conocida ([DZDs](#dzd-doublezero-device)) y dispositivos objetivo proporcionan pruebas firmadas criptográficamente de que un dispositivo se encuentra dentro de una cierta distancia de un punto de referencia. El registro onchain de las mediciones está planificado para una versión futura. Consulte [Geolocalización](geolocation.md) para la documentación de usuario. ### geoProbe -Un servidor bare metal que actúa como intermediario para las mediciones de latencia en el sistema de [Geolocalización](#geolocation). Los geoProbes están ubicados a ~1ms de un [DZD](#dzd-doublezero-device), reciben LocationOffsets firmados de los DZDs padre y miden el [RTT](#rtt-round-trip-time) hacia los dispositivos objetivo mediante [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmado o ICMP echo. Cada geoProbe se registra [onchain](#onchain) y se vincula a uno o más DZDs padre. Consulte [Despliegue de Geoprobe](contribute-geolocation.md) para la documentación de contribuidores. +Un servidor bare metal que actúa como intermediario para las mediciones de latencia en el sistema de [Geolocalización](#geolocation). Los geoProbes están ubicados a ~1ms de un [DZD](#dzd-doublezero-device), reciben LocationOffsets firmados de los DZDs principales y miden el [RTT](#rtt-round-trip-time) hacia los dispositivos objetivo mediante [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmado o eco ICMP. Cada geoProbe se registra [onchain](#onchain) y se vincula a uno o más DZDs principales. Consulte [Despliegue de Geoprobe](contribute-geolocation.md) para la documentación de contribuidores. ### LocationOffset -Una estructura de datos firmada que contiene la ubicación geográfica de un [DZD](#dzd-doublezero-device) (latitud y longitud) y una cadena de relaciones de latencia entre entidades (DZD↔Probe o Probe↔Target). Los LocationOffsets se firman con Ed25519 y se envían mediante UDP a través de la cadena de medición. Los offsets compuestos incluyen referencias a mediciones anteriores, creando un rastro auditable. +Una estructura de datos firmada que contiene la ubicación geográfica de un [DZD](#dzd-doublezero-device) (latitud y longitud) y una cadena de relaciones de latencia entre entidades (DZD↔Probe o Probe↔Target). Los LocationOffsets se firman con Ed25519 y se envían por UDP a través de la cadena de medición. Los offsets compuestos incluyen referencias a mediciones anteriores, creando un rastro auditable. --- ## Blockchain y Claves ### Onchain -En el contexto de DoubleZero, onchain se refiere a datos y operaciones registrados en el ledger de DoubleZero. A diferencia de las redes tradicionales donde las configuraciones de dispositivos y enlaces residen en sistemas de gestión centralizados, DoubleZero registra los registros de dispositivos, configuraciones de enlaces y envíos de telemetría onchain — haciendo que el estado de la red sea transparente y verificable por todos los participantes. +En el contexto de DoubleZero, onchain se refiere a los datos y operaciones registrados en el libro mayor de DoubleZero. A diferencia de las redes tradicionales donde las configuraciones de dispositivos y enlaces residen en sistemas de gestión centralizados, DoubleZero registra los registros de dispositivos, las configuraciones de enlaces y los envíos de telemetría onchain, haciendo que el estado de la red sea transparente y verificable por todos los participantes. ### Service Key -Un par de claves criptográficas utilizado para autenticar operaciones del CLI. Esta es su identidad de contribuidor para interactuar con el contrato inteligente de DoubleZero. Se almacena en `~/.config/solana/id.json`. +Un par de claves criptográficas utilizado para autenticar operaciones de CLI. Esta es su identidad de contribuidor para interactuar con el contrato inteligente de DoubleZero. Se almacena en `~/.config/solana/id.json`. ### Metrics Publisher Key -Un par de claves criptográficas utilizado por el [Telemetry Agent](#telemetry-agent) para firmar los envíos de métricas a la blockchain. Separado de la service key para aislamiento de seguridad. Se almacena en `~/.config/doublezero/metrics-publisher.json`. +Un par de claves criptográficas utilizado por el [Telemetry Agent](#telemetry-agent) para firmar los envíos de métricas a la blockchain. Separado de la clave de servicio por aislamiento de seguridad. Se almacena en `~/.config/doublezero/metrics-publisher.json`. ### Rewards Manager Key -Un par de claves criptográficas que controla dónde se pagan las recompensas de un contribuidor. Firma los cambios en la lista de billeteras destinatarias pero nunca retiene las recompensas en sí. Se registra contra la [Service Key](#service-key) del contribuidor por la [DZF](#dzf-doublezero-foundation). Consulte [Gestión de Recompensas](contribute-rewards.md). +Un par de claves criptográficas que controla dónde se pagan las recompensas de un contribuidor. Firma los cambios en la lista de billeteras receptoras pero nunca retiene recompensas por sí misma. Se mantiene separada de la [Service Key](#service-key). Consulte [Gestión de Recompensas](https://github.com/malbeclabs/contributors#rewards-management) en el repositorio de contribuidores. --- diff --git a/docs/glossary.fr.md b/docs/glossary.fr.md index 8bf565a..3e8a73d 100644 --- a/docs/glossary.fr.md +++ b/docs/glossary.fr.md @@ -11,32 +11,32 @@ Cette page définit la terminologie spécifique à DoubleZero utilisée dans l'e ## Infrastructure réseau ### DZD (DoubleZero Device) -Le matériel physique de commutation réseau qui termine les liens DoubleZero et exécute le logiciel DoubleZero Agent. Les DZD sont déployés dans les centres de données et fournissent des services de routage, de traitement de paquets et de connectivité utilisateur. Chaque DZD nécessite des [spécifications matérielles](contribute.md#dzd-network-hardware) précises et exécute à la fois le [Config Agent](#config-agent) et le [Telemetry Agent](#telemetry-agent). +Le matériel physique de commutation réseau qui termine les liens DoubleZero et exécute le logiciel DoubleZero Agent. Les DZD sont déployés dans les centres de données et fournissent des services de routage, de traitement des paquets et de connectivité utilisateur. Chaque DZD nécessite des [spécifications matérielles](contribute.md#dzd-network-hardware) spécifiques et exécute à la fois le [Config Agent](#config-agent) et le [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Points d'interconnexion dans le réseau maillé où les liens de différents [contributeurs](#contributor) sont reliés entre eux. Les DZX sont situés dans les grandes métropoles (par ex. NYC, LON, TYO) où se produisent les intersections réseau. Les contributeurs réseau doivent interconnecter leurs liens au maillage DoubleZero plus large au DZX le plus proche. Concept similaire à un point d'échange Internet (IX). +Points d'interconnexion dans le réseau maillé où les liens de différents [contributeurs](#contributor) sont pontés ensemble. Les DZX sont situés dans les grandes zones métropolitaines (par exemple, NYC, LON, TYO) où se produisent les intersections de réseau. Les contributeurs réseau doivent interconnecter leurs liens dans le maillage DoubleZero plus large au DZX le plus proche. Similaire dans le concept à un point d'échange Internet (IX). -### WAN Link -Un lien de réseau étendu (Wide Area Network) entre deux [DZD](#dzd-doublezero-device) exploités par le **même** contributeur. Les liens WAN fournissent la connectivité dorsale au sein de l'infrastructure d'un seul contributeur. +### Lien WAN +Un lien de réseau étendu (Wide Area Network) entre deux [DZD](#dzd-doublezero-device) exploités par le **même** contributeur. Les liens WAN fournissent une connectivité dorsale au sein de l'infrastructure d'un seul contributeur. -### DZX Link -Un lien entre des [DZD](#dzd-doublezero-device) exploités par des contributeurs **différents**, établi au niveau d'un [DZX](#dzx-doublezero-exchange). Les liens DZX nécessitent une acceptation explicite des deux parties. +### Lien DZX +Un lien entre des [DZD](#dzd-doublezero-device) exploités par des contributeurs **différents**, établi au niveau d'un [DZX](#dzx-doublezero-exchange). Les liens DZX nécessitent une acceptation explicite par les deux parties. -### DZ Prefix +### Préfixe DZ Allocations d'adresses IP au format CIDR attribuées à un [DZD](#dzd-doublezero-device) pour l'adressage du réseau overlay. Spécifié lors de la [création du dispositif](contribute-provisioning.md#step-32-create-your-device-onchain) à l'aide du paramètre `--dz-prefixes`. --- ## Types de dispositifs -### Edge Device -Un [DZD](#dzd-doublezero-device) qui fournit la connectivité utilisateur au réseau DoubleZero. Les dispositifs edge exploitent les interfaces [CYOA](#cyoa-choose-your-own-adventure) pour terminer les utilisateurs (validateurs, opérateurs RPC) et les connecter au réseau. +### Dispositif Edge +Un [DZD](#dzd-doublezero-device) qui fournit la connectivité utilisateur au réseau DoubleZero. Les dispositifs edge utilisent les interfaces [CYOA](#cyoa-choose-your-own-adventure) pour terminer les utilisateurs (validateurs, opérateurs RPC) et les connecter au réseau. -### Transit Device -Un [DZD](#dzd-doublezero-device) qui fournit la connectivité dorsale au sein du réseau DoubleZero. Les dispositifs transit acheminent le trafic entre les DZD mais ne terminent pas directement les connexions utilisateur. +### Dispositif Transit +Un [DZD](#dzd-doublezero-device) qui fournit une connectivité dorsale au sein du réseau DoubleZero. Les dispositifs transit acheminent le trafic entre les DZD mais ne terminent pas directement les connexions utilisateur. -### Hybrid Device -Un [DZD](#dzd-doublezero-device) qui combine les fonctionnalités [edge](#edge-device) et [transit](#transit-device), fournissant à la fois la connectivité utilisateur et le routage dorsal. +### Dispositif Hybride +Un [DZD](#dzd-doublezero-device) qui combine les fonctionnalités [edge](#dispositif-edge) et [transit](#dispositif-transit), fournissant à la fois la connectivité utilisateur et le routage dorsal. --- @@ -49,20 +49,20 @@ Types d'interfaces qui permettent aux [contributeurs](#contributor) d'enregistre Un terme réseau standard désignant la connectivité fournie via l'internet public. Dans DoubleZero, le DIA est un type d'interface [CYOA](#cyoa-choose-your-own-adventure) où les utilisateurs (validateurs, opérateurs RPC) se connectent à un [DZD](#dzd-doublezero-device) via leur connexion internet existante. ### IBRL (Increase Bandwidth Reduce Latency) -Un mode de connexion qui permet aux validateurs et aux nœuds RPC de se connecter à DoubleZero sans redémarrer leurs clients blockchain. IBRL utilise l'adresse IP publique existante et établit un tunnel overlay vers le [DZD](#dzd-doublezero-device) le plus proche. Voir [Connexion Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) pour les instructions de configuration. +Un mode de connexion qui permet aux validateurs et aux nœuds RPC de se connecter à DoubleZero sans redémarrer leurs clients blockchain. L'IBRL utilise l'adresse IP publique existante et établit un tunnel overlay vers le [DZD](#dzd-doublezero-device) le plus proche. Voir [Connexion Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) pour les instructions de configuration. ### Multicast -Une méthode de livraison de paquets de un vers plusieurs supportée par DoubleZero. Le mode multicast comporte deux rôles : **éditeur** (envoie des paquets à travers le réseau) et **abonné** (reçoit des paquets de l'éditeur). Utilisé par les équipes de développement pour une distribution efficace des données. Voir [Autre connexion Multicast](Other%20Multicast%20Connection.md) pour les détails de connexion. +Une méthode de livraison de paquets de type un-vers-plusieurs prise en charge par DoubleZero. Le mode multicast a deux rôles : **éditeur** (envoie des paquets à travers le réseau) et **abonné** (reçoit des paquets de l'éditeur). Utilisé par les équipes de développement pour une distribution efficace des données. Voir [Autre connexion Multicast](Other%20Multicast%20Connection.md) pour les détails de connexion. --- ## Composants logiciels ### doublezerod -Le service daemon DoubleZero qui s'exécute sur les serveurs des utilisateurs (validateurs, nœuds RPC). Il gère la connexion au réseau DoubleZero, assure l'établissement des tunnels et maintient la connectivité vers les [DZD](#dzd-doublezero-device). Configuré via systemd et contrôlé par la CLI [`doublezero`](#doublezero-cli). +Le service daemon DoubleZero qui s'exécute sur les serveurs des utilisateurs (validateurs, nœuds RPC). Il gère la connexion au réseau DoubleZero, gère l'établissement des tunnels et maintient la connectivité vers les [DZD](#dzd-doublezero-device). Configuré via systemd et contrôlé via la CLI [`doublezero`](#doublezero-cli). ### doublezero (CLI) -L'interface en ligne de commande pour interagir avec le réseau DoubleZero. Utilisée pour se connecter, gérer les identités, vérifier l'état et effectuer des opérations administratives. Communique avec le daemon [`doublezerod`](#doublezerod). +L'interface en ligne de commande pour interagir avec le réseau DoubleZero. Utilisée pour se connecter, gérer les identités, vérifier le statut et les opérations administratives. Communique avec le daemon [`doublezerod`](#doublezerod). ### Config Agent Agent logiciel s'exécutant sur les [DZD](#dzd-doublezero-device) qui gère la configuration des dispositifs. Lit la configuration depuis le service [Controller](#controller) et applique les modifications au dispositif. Voir [Installation du Config Agent](contribute-provisioning.md#step-44-install-config-agent) pour la mise en place. @@ -71,33 +71,33 @@ Agent logiciel s'exécutant sur les [DZD](#dzd-doublezero-device) qui gère la c Agent logiciel s'exécutant sur les [DZD](#dzd-doublezero-device) qui collecte les métriques de performance (latence, gigue, perte de paquets) et les soumet au registre DoubleZero. Voir [Installation du Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) pour la mise en place. ### Controller -Un service qui fournit la configuration aux agents des [DZD](#dzd-doublezero-device). Le Controller dérive les configurations des dispositifs à partir de l'état [onchain](#onchain) sur le registre DoubleZero. +Un service qui fournit la configuration aux agents des [DZD](#dzd-doublezero-device). Le Controller dérive les configurations des dispositifs à partir de l'état [onchain](#onchain) du registre DoubleZero. --- ## États des liens -### Activated -L'état opérationnel normal d'un lien. Le trafic circule à travers le lien et celui-ci participe aux décisions de routage. +### Activé +L'état opérationnel normal d'un lien. Le trafic circule à travers le lien et il participe aux décisions de routage. ### Soft-Drained -Un état de maintenance où le trafic sera découragé sur un lien spécifique. Utilisé pour des fenêtres de maintenance progressives. Peut transiter vers [activated](#activated) ou [hard-drained](#hard-drained). +Un état de maintenance où le trafic sera découragé sur un lien spécifique. Utilisé pour les fenêtres de maintenance progressives. Peut transitionner vers [activé](#activé) ou [hard-drained](#hard-drained). ### Hard-Drained -Un état de maintenance où le lien est complètement retiré du service. Aucun trafic ne circule à travers le lien. Doit transiter vers [soft-drained](#soft-drained) avant de revenir à [activated](#activated). +Un état de maintenance où le lien est complètement retiré du service. Aucun trafic ne circule à travers le lien. Doit transitionner vers [soft-drained](#soft-drained) avant de revenir à [activé](#activé). --- ## Organisations et jetons ### DZF (DoubleZero Foundation) -La DoubleZero Foundation est une société-fondation sans membres à but non lucratif des îles Caïmans, créée pour soutenir le développement, la décentralisation, la sécurité et l'adoption du réseau DoubleZero. +DoubleZero Foundation est une société-fondation sans membres des Îles Caïmans à but non lucratif qui a été créée pour soutenir le développement, la décentralisation, la sécurité et l'adoption du réseau DoubleZero. -### 2Z Token -Le jeton natif du réseau DoubleZero. Utilisé pour le paiement des frais de validateur et distribué en récompense aux [contributeurs](#contributor). Les validateurs peuvent payer les frais en 2Z via un programme d'échange onchain. Voir [Échanger des SOL en 2Z](Swapping-sol-to-2z.md). +### Jeton 2Z +Le jeton natif du réseau DoubleZero. Utilisé pour le paiement des frais de validateur et distribué comme récompenses aux [contributeurs](#contributor). Les validateurs peuvent payer les frais en 2Z via un programme d'échange onchain. Voir [Échange de SOL en 2Z](Swapping-sol-to-2z.md). ### Contributor -Un fournisseur d'infrastructure réseau qui contribue en bande passante et matériel au réseau DoubleZero. Les contributeurs exploitent des [DZD](#dzd-doublezero-device), fournissent des liens [WAN](#wan-link) et [DZX](#dzx-link), et reçoivent des incitations en jetons [2Z](#2z-token) pour leur contribution. Voir la [Documentation des contributeurs](contribute-overview.md) pour commencer. +Un fournisseur d'infrastructure réseau qui contribue en bande passante et en matériel au réseau DoubleZero. Les contributeurs exploitent des [DZD](#dzd-doublezero-device), fournissent des liens [WAN](#lien-wan) et [DZX](#lien-dzx), et reçoivent des incitations en jetons [2Z](#jeton-2z) pour leur contribution. Voir la [Documentation Contributeur](contribute-overview.md) pour commencer. --- @@ -110,67 +110,67 @@ La taille maximale de paquet (en octets) pouvant être transmise sur un lien ré Une technologie qui permet à plusieurs tables de routage isolées de coexister sur le même routeur physique. Les contributeurs utilisent souvent un VRF de gestion séparé pour isoler le trafic de gestion du commutateur du trafic de production. ### GRE (Generic Routing Encapsulation) -Un protocole de tunnelisation qui encapsule les paquets réseau dans des paquets IP. Utilisé par les connexions [IBRL](#ibrl-increase-bandwidth-reduce-latency) et [CYOA](#cyoa-choose-your-own-adventure) pour créer des tunnels overlay entre les utilisateurs et les DZD. +Un protocole de tunnelisation qui encapsule les paquets réseau à l'intérieur de paquets IP. Utilisé par les connexions [IBRL](#ibrl-increase-bandwidth-reduce-latency) et [CYOA](#cyoa-choose-your-own-adventure) pour créer des tunnels overlay entre les utilisateurs et les DZD. ### BGP (Border Gateway Protocol) -Le protocole de routage utilisé pour l'échange d'informations de routage entre les réseaux sur Internet. DoubleZero utilise BGP en interne avec l'ASN 65342. +Le protocole de routage utilisé pour l'échange d'informations de routage entre les réseaux sur Internet. DoubleZero utilise le BGP en interne avec l'ASN 65342. ### ASN (Autonomous System Number) Un identifiant unique attribué à un réseau pour le routage BGP. Tous les dispositifs DoubleZero utilisent l'**ASN 65342** pour le processus BGP interne. -### Loopback Interface +### Interface Loopback Une interface réseau virtuelle sur un routeur/commutateur utilisée à des fins de gestion et de routage. Les DZD utilisent Loopback255 (VPNv4) et Loopback256 (IPv4) pour le routage interne. ### CIDR (Classless Inter-Domain Routing) -Une notation pour spécifier les plages d'adresses IP. Le format est `IP/longueur-de-préfixe` où la longueur du préfixe indique la taille du réseau (par ex., `/29` = 8 adresses, `/24` = 256 adresses). +Une notation pour spécifier les plages d'adresses IP. Le format est `IP/longueur-de-préfixe` où la longueur du préfixe indique la taille du réseau (par exemple, `/29` = 8 adresses, `/24` = 256 adresses). -### Jitter +### Gigue Variation de la latence des paquets au fil du temps. Une faible gigue est essentielle pour les applications en temps réel. ### RTT (Round-Trip Time) Le temps nécessaire pour qu'un paquet voyage de la source à la destination et revienne. Utilisé pour mesurer la latence réseau entre les dispositifs. ### TWAMP (Two-Way Active Measurement Protocol) -Un protocole de mesure des métriques de performance réseau telles que la latence et la perte de paquets. Le [Telemetry Agent](#telemetry-agent) utilise TWAMP pour collecter les métriques entre les DZD. +Un protocole de mesure des métriques de performance réseau comme la latence et la perte de paquets. Le [Telemetry Agent](#telemetry-agent) utilise TWAMP pour collecter les métriques entre les DZD. ### IS-IS (Intermediate System to Intermediate System) -Un protocole de routage à état de lien utilisé en interne par le réseau DoubleZero. Les métriques IS-IS sont ajustées lors des opérations de [drainage de lien](#soft-drained). +Un protocole de routage à état de liens utilisé en interne par le réseau DoubleZero. Les métriques IS-IS sont ajustées lors des opérations de [drainage de lien](#soft-drained). --- ## Géolocalisation -### Geolocation +### Géolocalisation Un service DoubleZero qui vérifie l'emplacement physique des dispositifs à l'aide de mesures de latence. Les mesures de [RTT](#rtt-round-trip-time) entre l'infrastructure à emplacement connu ([DZD](#dzd-doublezero-device)) et les dispositifs cibles fournissent une preuve signée cryptographiquement qu'un dispositif se trouve à une certaine distance d'un point de référence. L'enregistrement onchain des mesures est prévu pour une version future. Voir [Géolocalisation](geolocation.md) pour la documentation utilisateur. ### geoProbe -Un serveur bare metal qui agit comme intermédiaire pour les mesures de latence dans le système de [Géolocalisation](#geolocation). Les geoProbes sont situés à ~1ms d'un [DZD](#dzd-doublezero-device), reçoivent des LocationOffsets signés des DZD parents et mesurent le [RTT](#rtt-round-trip-time) vers les dispositifs cibles via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP signé ou écho ICMP. Chaque geoProbe est enregistré [onchain](#onchain) et lié à un ou plusieurs DZD parents. Voir [Déploiement des Geoprobes](contribute-geolocation.md) pour la documentation des contributeurs. +Un serveur bare metal qui sert d'intermédiaire pour les mesures de latence dans le système de [Géolocalisation](#géolocalisation). Les geoProbes sont situés à ~1 ms d'un [DZD](#dzd-doublezero-device), reçoivent des LocationOffsets signés des DZD parents, et mesurent le [RTT](#rtt-round-trip-time) vers les dispositifs cibles via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP signé ou écho ICMP. Chaque geoProbe est enregistré [onchain](#onchain) et lié à un ou plusieurs DZD parents. Voir [Déploiement de Geoprobe](contribute-geolocation.md) pour la documentation contributeur. ### LocationOffset -Une structure de données signée contenant l'emplacement géographique (latitude et longitude) d'un [DZD](#dzd-doublezero-device) et une chaîne de relations de latence entre entités (DZD↔Probe ou Probe↔Cible). Les LocationOffsets sont signés avec Ed25519 et envoyés via UDP à travers la chaîne de mesure. Les offsets composites incluent des références aux mesures précédentes, créant une piste d'audit vérifiable. +Une structure de données signée contenant l'emplacement géographique d'un [DZD](#dzd-doublezero-device) (latitude et longitude) et une chaîne de relations de latence entre les entités (DZD↔Probe ou Probe↔Cible). Les LocationOffsets sont signés avec Ed25519 et envoyés via UDP à travers la chaîne de mesure. Les offsets composites incluent des références aux mesures précédentes, créant une piste d'audit vérifiable. --- ## Blockchain et clés ### Onchain -Dans le contexte DoubleZero, onchain fait référence aux données et opérations enregistrées sur le registre DoubleZero. Contrairement aux réseaux traditionnels où les configurations des dispositifs et des liens résident dans des systèmes de gestion centralisés, DoubleZero enregistre les inscriptions de dispositifs, les configurations de liens et les soumissions de télémétrie onchain — rendant l'état du réseau transparent et vérifiable par tous les participants. +Dans le contexte DoubleZero, onchain fait référence aux données et opérations enregistrées sur le registre DoubleZero. Contrairement aux réseaux traditionnels où les configurations de dispositifs et de liens résident dans des systèmes de gestion centralisés, DoubleZero enregistre les enregistrements de dispositifs, les configurations de liens et les soumissions de télémétrie onchain — rendant l'état du réseau transparent et vérifiable par tous les participants. -### Service Key -Une paire de clés cryptographiques utilisée pour authentifier les opérations CLI. Il s'agit de votre identité de contributeur pour interagir avec le contrat intelligent DoubleZero. Stockée à `~/.config/solana/id.json`. +### Clé de service +Une paire de clés cryptographiques utilisée pour authentifier les opérations CLI. Il s'agit de votre identité de contributeur pour interagir avec le contrat intelligent DoubleZero. Stockée dans `~/.config/solana/id.json`. -### Metrics Publisher Key -Une paire de clés cryptographiques utilisée par le [Telemetry Agent](#telemetry-agent) pour signer les soumissions de métriques à la blockchain. Séparée de la clé de service pour l'isolation de sécurité. Stockée à `~/.config/doublezero/metrics-publisher.json`. +### Clé de publication de métriques +Une paire de clés cryptographiques utilisée par le [Telemetry Agent](#telemetry-agent) pour signer les soumissions de métriques à la blockchain. Séparée de la clé de service pour l'isolation de sécurité. Stockée dans `~/.config/doublezero/metrics-publisher.json`. -### Rewards Manager Key -Une paire de clés cryptographiques qui contrôle où les récompenses d'un contributeur sont versées. Elle signe les modifications de la liste des portefeuilles destinataires mais ne détient jamais elle-même les récompenses. Enregistrée contre la [Service Key](#service-key) du contributeur par la [DZF](#dzf-doublezero-foundation). Voir [Gestion des récompenses](contribute-rewards.md). +### Clé du gestionnaire de récompenses +Une paire de clés cryptographiques qui contrôle où les récompenses d'un contributeur sont versées. Elle signe les modifications de la liste des portefeuilles destinataires mais ne détient jamais de récompenses elle-même. Maintenue séparée de la [Clé de service](#clé-de-service). Voir [Gestion des récompenses](https://github.com/malbeclabs/contributors#rewards-management) dans le dépôt des contributeurs. --- -## Matériel et logiciel +## Matériel et logiciels ### EOS (Extensible Operating System) Le système d'exploitation réseau d'Arista qui s'exécute sur les commutateurs DZD. Les contributeurs installent le [Config Agent](#config-agent) et le [Telemetry Agent](#telemetry-agent) en tant qu'extensions EOS. -### EOS Extension -Un paquet logiciel pouvant être installé sur les commutateurs Arista EOS. Les agents DZ sont distribués sous forme de fichiers `.rpm` et installés via la commande `extension`. \ No newline at end of file +### Extension EOS +Un package logiciel pouvant être installé sur les commutateurs Arista EOS. Les agents DZ sont distribués sous forme de fichiers `.rpm` et installés via la commande `extension`. \ No newline at end of file diff --git a/docs/glossary.it.md b/docs/glossary.it.md index 0c9ff39..ab57bb3 100644 --- a/docs/glossary.it.md +++ b/docs/glossary.it.md @@ -11,16 +11,16 @@ Questa pagina definisce la terminologia specifica di DoubleZero utilizzata in tu ## Infrastruttura di Rete ### DZD (DoubleZero Device) -L'hardware fisico di switching di rete che termina i collegamenti DoubleZero ed esegue il software DoubleZero Agent. I DZD sono distribuiti nei data center e forniscono servizi di routing, elaborazione dei pacchetti e connettività utente. Ogni DZD richiede [specifiche hardware](contribute.md#dzd-network-hardware) specifiche ed esegue sia il [Config Agent](#config-agent) che il [Telemetry Agent](#telemetry-agent). +L'hardware di commutazione di rete fisico che termina i link DoubleZero e esegue il software DoubleZero Agent. I DZD sono distribuiti nei data center e forniscono servizi di routing, elaborazione dei pacchetti e connettività utente. Ogni DZD richiede [specifiche hardware](contribute.md#dzd-network-hardware) specifiche e esegue sia il [Config Agent](#config-agent) che il [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Punti di interconnessione nella rete mesh in cui vengono collegati i link di diversi [contributor](#contributor). I DZX si trovano nelle principali aree metropolitane (ad es. NYC, LON, TYO) dove si verificano le intersezioni di rete. I contributor della rete devono effettuare il cross-connect dei propri link nella mesh DoubleZero più ampia presso il DZX più vicino. Concetto simile a un Internet Exchange (IX). +Punti di interconnessione nella rete mesh in cui i link di diversi [contributori](#contributor) vengono collegati insieme. I DZX si trovano nelle principali aree metropolitane (ad es., NYC, LON, TYO) dove si verificano intersezioni di rete. I contributori della rete devono effettuare il cross-connect dei propri link nella mesh DoubleZero più ampia presso il DZX più vicino. Concetto simile a un Internet Exchange (IX). ### WAN Link -Un collegamento Wide Area Network tra due [DZD](#dzd-doublezero-device) gestiti dallo **stesso** contributor. I WAN link forniscono connettività backbone all'interno dell'infrastruttura di un singolo contributor. +Un link di Wide Area Network tra due [DZD](#dzd-doublezero-device) gestiti dallo **stesso** contributore. I link WAN forniscono connettività backbone all'interno dell'infrastruttura di un singolo contributore. ### DZX Link -Un collegamento tra [DZD](#dzd-doublezero-device) gestiti da contributor **diversi**, stabilito presso un [DZX](#dzx-doublezero-exchange). I DZX link richiedono l'accettazione esplicita da entrambe le parti. +Un link tra [DZD](#dzd-doublezero-device) gestiti da contributori **diversi**, stabilito presso un [DZX](#dzx-doublezero-exchange). I link DZX richiedono l'accettazione esplicita da entrambe le parti. ### DZ Prefix Allocazioni di indirizzi IP in formato CIDR assegnate a un [DZD](#dzd-doublezero-device) per l'indirizzamento della rete overlay. Specificati durante la [creazione del dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) utilizzando il parametro `--dz-prefixes`. @@ -30,90 +30,90 @@ Allocazioni di indirizzi IP in formato CIDR assegnate a un [DZD](#dzd-doublezero ## Tipi di Dispositivo ### Edge Device -Un [DZD](#dzd-doublezero-device) che fornisce connettività utente alla rete DoubleZero. Gli edge device sfruttano le interfacce [CYOA](#cyoa-choose-your-own-adventure) per terminare gli utenti (validatori, operatori RPC) e collegarli alla rete. +Un [DZD](#dzd-doublezero-device) che fornisce connettività utente alla rete DoubleZero. I dispositivi edge sfruttano le interfacce [CYOA](#cyoa-choose-your-own-adventure) per terminare gli utenti (validatori, operatori RPC) e collegarli alla rete. ### Transit Device -Un [DZD](#dzd-doublezero-device) che fornisce connettività backbone all'interno della rete DoubleZero. I transit device trasferiscono il traffico tra i DZD ma non terminano direttamente le connessioni utente. +Un [DZD](#dzd-doublezero-device) che fornisce connettività backbone all'interno della rete DoubleZero. I dispositivi transit spostano il traffico tra i DZD ma non terminano direttamente le connessioni utente. ### Hybrid Device -Un [DZD](#dzd-doublezero-device) che combina le funzionalità sia di [edge](#edge-device) che di [transit](#transit-device), fornendo sia connettività utente che routing backbone. +Un [DZD](#dzd-doublezero-device) che combina le funzionalità sia [edge](#edge-device) che [transit](#transit-device), fornendo sia connettività utente che routing backbone. --- ## Connettività ### CYOA (Choose Your Own Adventure) -Tipi di interfaccia che consentono ai [contributor](#contributor) di registrare opzioni di connettività per gli utenti che si collegano alla rete DoubleZero. Le interfacce CYOA includono vari metodi come [DIA](#dia-direct-internet-access), tunnel GRE e peering privato. Consulta [Creazione delle interfacce CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) per i dettagli di configurazione. +Tipi di interfaccia che consentono ai [contributori](#contributor) di registrare opzioni di connettività per gli utenti che si collegano alla rete DoubleZero. Le interfacce CYOA includono vari metodi come [DIA](#dia-direct-internet-access), tunnel GRE e peering privato. Vedere [Creazione delle Interfacce CYOA](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices) per i dettagli di configurazione. ### DIA (Direct Internet Access) -Un termine di networking standard per la connettività fornita tramite Internet pubblica. In DoubleZero, DIA è un tipo di interfaccia [CYOA](#cyoa-choose-your-own-adventure) in cui gli utenti (validatori, operatori RPC) si connettono a un [DZD](#dzd-doublezero-device) tramite la propria connessione Internet esistente. +Un termine di rete standard per la connettività fornita tramite internet pubblico. In DoubleZero, DIA è un tipo di interfaccia [CYOA](#cyoa-choose-your-own-adventure) in cui gli utenti (validatori, operatori RPC) si collegano a un [DZD](#dzd-doublezero-device) tramite la loro connessione internet esistente. ### IBRL (Increase Bandwidth Reduce Latency) -Una modalità di connessione che consente a validatori e nodi RPC di connettersi a DoubleZero senza riavviare i propri client blockchain. IBRL utilizza l'indirizzo IP pubblico esistente e stabilisce un tunnel overlay verso il [DZD](#dzd-doublezero-device) più vicino. Consulta [Connessione Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) per le istruzioni di configurazione. +Una modalità di connessione che consente a validatori e nodi RPC di collegarsi a DoubleZero senza riavviare i propri client blockchain. IBRL utilizza l'indirizzo IP pubblico esistente e stabilisce un tunnel overlay verso il [DZD](#dzd-doublezero-device) più vicino. Vedere [Connessione Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) per le istruzioni di configurazione. ### Multicast -Un metodo di consegna dei pacchetti uno-a-molti supportato da DoubleZero. La modalità multicast prevede due ruoli: **publisher** (invia pacchetti attraverso la rete) e **subscriber** (riceve pacchetti dal publisher). Utilizzato dai team di sviluppo per la distribuzione efficiente dei dati. Consulta [Altra connessione Multicast](Other%20Multicast%20Connection.md) per i dettagli di connessione. +Un metodo di consegna dei pacchetti uno-a-molti supportato da DoubleZero. La modalità multicast ha due ruoli: **publisher** (invia pacchetti attraverso la rete) e **subscriber** (riceve pacchetti dal publisher). Utilizzato dai team di sviluppo per una distribuzione efficiente dei dati. Vedere [Altra Connessione Multicast](Other%20Multicast%20Connection.md) per i dettagli di connessione. --- ## Componenti Software ### doublezerod -Il servizio daemon DoubleZero che viene eseguito sui server degli utenti (validatori, nodi RPC). Gestisce la connessione alla rete DoubleZero, si occupa dell'instaurazione dei tunnel e mantiene la connettività verso i [DZD](#dzd-doublezero-device). Configurato tramite systemd e controllato attraverso la CLI [`doublezero`](#doublezero-cli). +Il servizio daemon DoubleZero che viene eseguito sui server degli utenti (validatori, nodi RPC). Gestisce la connessione alla rete DoubleZero, gestisce la creazione dei tunnel e mantiene la connettività verso i [DZD](#dzd-doublezero-device). Configurato tramite systemd e controllato attraverso la CLI [`doublezero`](#doublezero-cli). ### doublezero (CLI) L'interfaccia a riga di comando per interagire con la rete DoubleZero. Utilizzata per connettersi, gestire le identità, verificare lo stato e le operazioni amministrative. Comunica con il daemon [`doublezerod`](#doublezerod). ### Config Agent -Agente software in esecuzione sui [DZD](#dzd-doublezero-device) che gestisce la configurazione del dispositivo. Legge la configurazione dal servizio [Controller](#controller) e applica le modifiche al dispositivo. Consulta [Installazione del Config Agent](contribute-provisioning.md#step-44-install-config-agent) per la configurazione. +Agente software in esecuzione sui [DZD](#dzd-doublezero-device) che gestisce la configurazione del dispositivo. Legge la configurazione dal servizio [Controller](#controller) e applica le modifiche al dispositivo. Vedere [Installazione del Config Agent](contribute-provisioning.md#step-44-install-config-agent) per la configurazione. ### Telemetry Agent -Agente software in esecuzione sui [DZD](#dzd-doublezero-device) che raccoglie metriche di prestazione (latenza, jitter, perdita di pacchetti) e le invia al ledger DoubleZero. Consulta [Installazione del Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) per la configurazione. +Agente software in esecuzione sui [DZD](#dzd-doublezero-device) che raccoglie metriche di prestazione (latenza, jitter, perdita di pacchetti) e le invia al ledger DoubleZero. Vedere [Installazione del Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) per la configurazione. ### Controller -Un servizio che fornisce la configurazione agli agenti dei [DZD](#dzd-doublezero-device). Il Controller deriva le configurazioni dei dispositivi dallo stato [onchain](#onchain) sul ledger DoubleZero. +Un servizio che fornisce la configurazione agli agenti [DZD](#dzd-doublezero-device). Il Controller deriva le configurazioni dei dispositivi dallo stato [onchain](#onchain) sul ledger DoubleZero. --- ## Stati dei Link ### Activated -Lo stato operativo normale per un link. Il traffico fluisce attraverso il link e questo partecipa alle decisioni di routing. +Lo stato operativo normale per un link. Il traffico fluisce attraverso il link e partecipa alle decisioni di routing. ### Soft-Drained -Uno stato di manutenzione in cui il traffico viene disincentivato su un link specifico. Utilizzato per finestre di manutenzione graduali. Può passare allo stato [activated](#activated) o [hard-drained](#hard-drained). +Uno stato di manutenzione in cui il traffico viene scoraggiato su un link specifico. Utilizzato per finestre di manutenzione graduali. Può transitare verso [activated](#activated) o [hard-drained](#hard-drained). ### Hard-Drained -Uno stato di manutenzione in cui il link è completamente rimosso dal servizio. Nessun traffico fluisce attraverso il link. Deve passare allo stato [soft-drained](#soft-drained) prima di tornare ad [activated](#activated). +Uno stato di manutenzione in cui il link è completamente rimosso dal servizio. Nessun traffico fluisce attraverso il link. Deve transitare verso [soft-drained](#soft-drained) prima di tornare ad [activated](#activated). --- ## Organizzazioni e Token ### DZF (DoubleZero Foundation) -DoubleZero Foundation è una fondazione senza scopo di lucro e senza membri, costituita come foundation company nelle Isole Cayman, creata per supportare lo sviluppo, la decentralizzazione, la sicurezza e l'adozione della rete DoubleZero. +DoubleZero Foundation è una società fondazione senza membri delle Isole Cayman senza scopo di lucro, costituita per supportare lo sviluppo, la decentralizzazione, la sicurezza e l'adozione della rete DoubleZero. ### 2Z Token -Il token nativo della rete DoubleZero. Utilizzato per il pagamento delle commissioni dei validatori e distribuito come ricompense ai [contributor](#contributor). I validatori possono pagare le commissioni in 2Z tramite un programma di swap onchain. Consulta [Swap da SOL a 2Z](Swapping-sol-to-2z.md). +Il token nativo della rete DoubleZero. Utilizzato per pagare le commissioni dei validatori e distribuito come ricompense ai [contributori](#contributor). I validatori possono pagare le commissioni in 2Z tramite un programma di swap onchain. Vedere [Scambio da SOL a 2Z](Swapping-sol-to-2z.md). ### Contributor -Un fornitore di infrastruttura di rete che contribuisce con larghezza di banda e hardware alla rete DoubleZero. I contributor gestiscono i [DZD](#dzd-doublezero-device), forniscono link [WAN](#wan-link) e [DZX](#dzx-link) e ricevono incentivi in token [2Z](#2z-token) per il loro contributo. Consulta la [Documentazione per i Contributor](contribute-overview.md) per iniziare. +Un fornitore di infrastruttura di rete che contribuisce con banda e hardware alla rete DoubleZero. I contributori gestiscono [DZD](#dzd-doublezero-device), forniscono link [WAN](#wan-link) e [DZX](#dzx-link), e ricevono incentivi in token [2Z](#2z-token) per il loro contributo. Vedere la [Documentazione per i Contributori](contribute-overview.md) per iniziare. --- ## Concetti di Rete ### MTU (Maximum Transmission Unit) -La dimensione massima del pacchetto (in byte) che può essere trasmessa su un collegamento di rete. I WAN link di DoubleZero utilizzano tipicamente MTU 9000 (jumbo frame) per efficienza. +La dimensione massima del pacchetto (in byte) che può essere trasmessa su un link di rete. I link WAN di DoubleZero utilizzano tipicamente MTU 9000 (jumbo frame) per maggiore efficienza. ### VRF (Virtual Routing and Forwarding) -Una tecnologia che consente a più tabelle di routing isolate di coesistere sullo stesso router fisico. I contributor spesso utilizzano un VRF di gestione separato per isolare il traffico di gestione dello switch dal traffico di produzione. +Una tecnologia che consente a più tabelle di routing isolate di coesistere sullo stesso router fisico. I contributori spesso utilizzano un VRF di gestione separato per isolare il traffico di gestione dello switch dal traffico di produzione. ### GRE (Generic Routing Encapsulation) Un protocollo di tunneling che incapsula i pacchetti di rete all'interno di pacchetti IP. Utilizzato dalle connessioni [IBRL](#ibrl-increase-bandwidth-reduce-latency) e [CYOA](#cyoa-choose-your-own-adventure) per creare tunnel overlay tra utenti e DZD. ### BGP (Border Gateway Protocol) -Il protocollo di routing utilizzato per lo scambio di informazioni di routing tra reti su Internet. DoubleZero utilizza BGP internamente con ASN 65342. +Il protocollo di routing utilizzato per lo scambio di informazioni di routing tra reti su internet. DoubleZero utilizza BGP internamente con ASN 65342. ### ASN (Autonomous System Number) Un identificatore univoco assegnato a una rete per il routing BGP. Tutti i dispositivi DoubleZero utilizzano **ASN 65342** per il processo BGP interno. @@ -122,13 +122,13 @@ Un identificatore univoco assegnato a una rete per il routing BGP. Tutti i dispo Un'interfaccia di rete virtuale su un router/switch utilizzata per scopi di gestione e routing. I DZD utilizzano Loopback255 (VPNv4) e Loopback256 (IPv4) per il routing interno. ### CIDR (Classless Inter-Domain Routing) -Una notazione per specificare intervalli di indirizzi IP. Il formato è `IP/lunghezza-prefisso` dove la lunghezza del prefisso indica la dimensione della rete (ad es. `/29` = 8 indirizzi, `/24` = 256 indirizzi). +Una notazione per specificare intervalli di indirizzi IP. Il formato è `IP/prefix-length` dove la lunghezza del prefisso indica la dimensione della rete (ad es., `/29` = 8 indirizzi, `/24` = 256 indirizzi). ### Jitter Variazione nella latenza dei pacchetti nel tempo. Un jitter basso è fondamentale per le applicazioni in tempo reale. ### RTT (Round-Trip Time) -Il tempo impiegato da un pacchetto per viaggiare dalla sorgente alla destinazione e tornare indietro. Utilizzato per misurare la latenza di rete tra i dispositivi. +Il tempo necessario affinché un pacchetto viaggi dalla sorgente alla destinazione e ritorno. Utilizzato per misurare la latenza di rete tra i dispositivi. ### TWAMP (Two-Way Active Measurement Protocol) Un protocollo per misurare le metriche di prestazione della rete come latenza e perdita di pacchetti. Il [Telemetry Agent](#telemetry-agent) utilizza TWAMP per raccogliere metriche tra i DZD. @@ -140,11 +140,11 @@ Un protocollo di routing link-state utilizzato internamente dalla rete DoubleZer ## Geolocalizzazione -### Geolocalizzazione -Un servizio DoubleZero che verifica la posizione fisica dei dispositivi utilizzando misurazioni di latenza. Le misurazioni [RTT](#rtt-round-trip-time) tra infrastrutture a posizione nota ([DZD](#dzd-doublezero-device)) e dispositivi target forniscono una prova firmata crittograficamente che un dispositivo si trova entro una certa distanza da un punto di riferimento. La registrazione onchain delle misurazioni è prevista per una versione futura. Consulta [Geolocalizzazione](geolocation.md) per la documentazione utente. +### Geolocation +Un servizio DoubleZero che verifica la posizione fisica dei dispositivi utilizzando misurazioni di latenza. Le misurazioni [RTT](#rtt-round-trip-time) tra infrastrutture a posizione nota ([DZD](#dzd-doublezero-device)) e dispositivi target forniscono una prova firmata crittograficamente che un dispositivo si trova entro una certa distanza da un punto di riferimento. La registrazione onchain delle misurazioni è prevista per una versione futura. Vedere [Geolocalizzazione](geolocation.md) per la documentazione utente. ### geoProbe -Un server bare metal che funge da intermediario per le misurazioni di latenza nel sistema di [Geolocalizzazione](#geolocalizzazione). I geoProbe si trovano entro ~1ms da un [DZD](#dzd-doublezero-device), ricevono LocationOffset firmati dai DZD parent e misurano l'[RTT](#rtt-round-trip-time) verso i dispositivi target tramite [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmato o ICMP echo. Ogni geoProbe è registrato [onchain](#onchain) e collegato a uno o più DZD parent. Consulta [Deployment dei Geoprobe](contribute-geolocation.md) per la documentazione dei contributor. +Un server bare metal che funge da intermediario per le misurazioni di latenza nel sistema di [Geolocalizzazione](#geolocation). I geoProbe sono posizionati entro ~1ms da un [DZD](#dzd-doublezero-device), ricevono LocationOffset firmati dai DZD parent e misurano l'[RTT](#rtt-round-trip-time) verso i dispositivi target tramite [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP firmato o ICMP echo. Ogni geoProbe è registrato [onchain](#onchain) e collegato a uno o più DZD parent. Vedere [Distribuzione dei Geoprobe](contribute-geolocation.md) per la documentazione dei contributori. ### LocationOffset Una struttura dati firmata contenente la posizione geografica di un [DZD](#dzd-doublezero-device) (latitudine e longitudine) e una catena di relazioni di latenza tra entità (DZD↔Probe o Probe↔Target). I LocationOffset sono firmati con Ed25519 e inviati tramite UDP attraverso la catena di misurazione. Gli offset compositi includono riferimenti a misurazioni precedenti, creando una traccia verificabile. @@ -157,20 +157,20 @@ Una struttura dati firmata contenente la posizione geografica di un [DZD](#dzd-d Nel contesto DoubleZero, onchain si riferisce a dati e operazioni registrati sul ledger DoubleZero. A differenza delle reti tradizionali in cui le configurazioni di dispositivi e link risiedono in sistemi di gestione centralizzati, DoubleZero registra le registrazioni dei dispositivi, le configurazioni dei link e le sottomissioni di telemetria onchain — rendendo lo stato della rete trasparente e verificabile da tutti i partecipanti. ### Service Key -Una coppia di chiavi crittografiche utilizzata per autenticare le operazioni CLI. Questa è la vostra identità di contributor per interagire con lo smart contract DoubleZero. Memorizzata in `~/.config/solana/id.json`. +Una coppia di chiavi crittografiche utilizzata per autenticare le operazioni CLI. Questa è la tua identità di contributore per interagire con lo smart contract DoubleZero. Memorizzata in `~/.config/solana/id.json`. ### Metrics Publisher Key Una coppia di chiavi crittografiche utilizzata dal [Telemetry Agent](#telemetry-agent) per firmare le sottomissioni di metriche alla blockchain. Separata dalla service key per l'isolamento della sicurezza. Memorizzata in `~/.config/doublezero/metrics-publisher.json`. ### Rewards Manager Key -Una coppia di chiavi crittografiche che controlla dove vengono pagati i premi di un contributor. Firma le modifiche all'elenco dei wallet destinatari ma non detiene mai direttamente i premi. Registrata rispetto alla [Service Key](#service-key) del contributor da [DZF](#dzf-doublezero-foundation). Consulta [Gestione dei Premi](contribute-rewards.md). +Una coppia di chiavi crittografiche che controlla dove vengono pagate le ricompense di un contributore. Firma le modifiche alla lista dei wallet destinatari ma non detiene mai direttamente le ricompense. Mantenuta separata dalla [Service Key](#service-key). Vedere [Gestione delle Ricompense](https://github.com/malbeclabs/contributors#rewards-management) nel repository dei contributori. --- ## Hardware e Software ### EOS (Extensible Operating System) -Il sistema operativo di rete di Arista che viene eseguito sugli switch DZD. I contributor installano il [Config Agent](#config-agent) e il [Telemetry Agent](#telemetry-agent) come estensioni EOS. +Il sistema operativo di rete di Arista che viene eseguito sugli switch DZD. I contributori installano il [Config Agent](#config-agent) e il [Telemetry Agent](#telemetry-agent) come estensioni EOS. ### EOS Extension Un pacchetto software che può essere installato sugli switch Arista EOS. Gli agenti DZ sono distribuiti come file `.rpm` e installati tramite il comando `extension`. \ No newline at end of file diff --git a/docs/glossary.ja.md b/docs/glossary.ja.md index 84b7a20..ae5d013 100644 --- a/docs/glossary.ja.md +++ b/docs/glossary.ja.md @@ -14,16 +14,16 @@ description: ドキュメント全体で使用されるDoubleZero固有の用語 DoubleZeroリンクを終端し、DoubleZero Agentソフトウェアを実行する物理ネットワークスイッチングハードウェア。DZDはデータセンターに展開され、ルーティング、パケット処理、およびユーザー接続サービスを提供します。各DZDには特定の[ハードウェア仕様](contribute.md#dzd-network-hardware)が必要であり、[Config Agent](#config-agent)と[Telemetry Agent](#telemetry-agent)の両方を実行します。 ### DZX (DoubleZero Exchange) -メッシュネットワーク内の相互接続ポイントで、異なる[コントリビューター](#contributor)のリンクがブリッジされる場所です。DZXは、ネットワークの交差点が発生する主要な都市圏（例：NYC、LON、TYO）に設置されています。ネットワークコントリビューターは、最寄りのDZXで自身のリンクをより広範なDoubleZeroメッシュにクロスコネクトする必要があります。Internet Exchange (IX) と同様の概念です。 +メッシュネットワーク内の相互接続ポイントで、異なる[コントリビューター](#contributor)のリンクがブリッジされます。DZXは、ネットワークの交差点が発生する主要な大都市圏（例：NYC、LON、TYO）に配置されています。ネットワークコントリビューターは、最寄りのDZXで自身のリンクをより広範なDoubleZeroメッシュにクロスコネクトする必要があります。Internet Exchange（IX）と類似した概念です。 ### WANリンク -**同一の**コントリビューターによって運用される2つの[DZD](#dzd-doublezero-device)間のWide Area Networkリンク。WANリンクは、単一のコントリビューターのインフラストラクチャ内でバックボーン接続を提供します。 +**同一の**コントリビューターが運用する2つの[DZD](#dzd-doublezero-device)間のWide Area Networkリンク。WANリンクは、単一のコントリビューターのインフラストラクチャ内でバックボーン接続を提供します。 ### DZXリンク -[DZX](#dzx-doublezero-exchange)で確立される、**異なる**コントリビューターによって運用される[DZD](#dzd-doublezero-device)間のリンク。DZXリンクは双方の明示的な承認が必要です。 +[DZX](#dzx-doublezero-exchange)において、**異なる**コントリビューターが運用する[DZD](#dzd-doublezero-device)間で確立されるリンク。DZXリンクは、双方による明示的な承認が必要です。 ### DZプレフィックス -オーバーレイネットワークアドレッシングのために[DZD](#dzd-doublezero-device)に割り当てられたCIDR形式のIPアドレス割り当て。[デバイス作成](contribute-provisioning.md#step-32-create-your-device-onchain)時に`--dz-prefixes`パラメータを使用して指定します。 +オーバーレイネットワークアドレッシングのために[DZD](#dzd-doublezero-device)に割り当てられるCIDR形式のIPアドレス割り当て。[デバイス作成](contribute-provisioning.md#step-32-create-your-device-onchain)時に`--dz-prefixes`パラメータを使用して指定します。 --- @@ -36,33 +36,33 @@ DoubleZeroネットワークへのユーザー接続を提供する[DZD](#dzd-do DoubleZeroネットワーク内でバックボーン接続を提供する[DZD](#dzd-doublezero-device)。トランジットデバイスはDZD間のトラフィックを転送しますが、ユーザー接続を直接終端することはありません。 ### ハイブリッドデバイス -[エッジ](#edge-device)と[トランジット](#transit-device)の両方の機能を兼ね備えた[DZD](#dzd-doublezero-device)で、ユーザー接続とバックボーンルーティングの両方を提供します。 +[エッジ](#エッジデバイス)と[トランジット](#トランジットデバイス)の両方の機能を組み合わせた[DZD](#dzd-doublezero-device)で、ユーザー接続とバックボーンルーティングの両方を提供します。 --- ## 接続性 ### CYOA (Choose Your Own Adventure) -[コントリビューター](#contributor)がユーザーのDoubleZeroネットワークへの接続オプションを登録できるインターフェースタイプ。CYOAインターフェースには、[DIA](#dia-direct-internet-access)、GREトンネル、プライベートピアリングなど、さまざまな方法が含まれます。設定の詳細については[CYOAインターフェースの作成](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)を参照してください。 +[コントリビューター](#contributor)がDoubleZeroネットワークへのユーザー接続オプションを登録できるインターフェースタイプ。CYOAインターフェースには、[DIA](#dia-direct-internet-access)、GREトンネル、プライベートピアリングなど、さまざまな方法が含まれます。設定の詳細は[CYOAインターフェースの作成](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)を参照してください。 ### DIA (Direct Internet Access) -パブリックインターネット経由で提供される接続に関する標準的なネットワーキング用語。DoubleZeroでは、DIAはユーザー（バリデーター、RPCオペレーター）が既存のインターネット接続を通じて[DZD](#dzd-doublezero-device)に接続する[CYOA](#cyoa-choose-your-own-adventure)インターフェースタイプです。 +パブリックインターネット経由で提供される接続を指す標準的なネットワーク用語。DoubleZeroでは、DIAはユーザー（バリデーター、RPCオペレーター）が既存のインターネット接続を通じて[DZD](#dzd-doublezero-device)に接続する[CYOA](#cyoa-choose-your-own-adventure)インターフェースタイプです。 ### IBRL (Increase Bandwidth Reduce Latency) -バリデーターやRPCノードがブロックチェーンクライアントを再起動せずにDoubleZeroに接続できる接続モード。IBRLは既存のパブリックIPアドレスを使用し、最寄りの[DZD](#dzd-doublezero-device)へのオーバーレイトンネルを確立します。セットアップ手順については[Mainnet-Beta接続](DZ%20Mainnet-beta%20Connection.md)を参照してください。 +バリデーターやRPCノードがブロックチェーンクライアントを再起動せずにDoubleZeroに接続できる接続モード。IBRLは既存のパブリックIPアドレスを使用し、最寄りの[DZD](#dzd-doublezero-device)へのオーバーレイトンネルを確立します。セットアップ手順は[Mainnet-Beta接続](DZ%20Mainnet-beta%20Connection.md)を参照してください。 ### マルチキャスト -DoubleZeroがサポートする1対多のパケット配信方式。マルチキャストモードには、**パブリッシャー**（ネットワーク全体にパケットを送信）と**サブスクライバー**（パブリッシャーからパケットを受信）の2つの役割があります。開発チームが効率的なデータ配信に使用します。接続の詳細については[その他のマルチキャスト接続](Other%20Multicast%20Connection.md)を参照してください。 +DoubleZeroがサポートする1対多のパケット配信方式。マルチキャストモードには2つの役割があります：**パブリッシャー**（ネットワーク全体にパケットを送信）と**サブスクライバー**（パブリッシャーからパケットを受信）。開発チームによる効率的なデータ配信に使用されます。接続の詳細は[その他のマルチキャスト接続](Other%20Multicast%20Connection.md)を参照してください。 --- ## ソフトウェアコンポーネント ### doublezerod -ユーザーサーバー（バリデーター、RPCノード）上で実行されるDoubleZeroデーモンサービス。DoubleZeroネットワークへの接続を管理し、トンネルの確立を処理し、[DZD](#dzd-doublezero-device)への接続性を維持します。systemdを介して設定され、[`doublezero`](#doublezero-cli) CLIを通じて制御されます。 +ユーザーサーバー（バリデーター、RPCノード）上で実行されるDoubleZeroデーモンサービス。DoubleZeroネットワークへの接続を管理し、トンネルの確立を処理し、[DZD](#dzd-doublezero-device)への接続を維持します。systemdを介して設定され、[`doublezero`](#doublezero-cli) CLIを通じて制御されます。 ### doublezero (CLI) -DoubleZeroネットワークとやり取りするためのコマンドラインインターフェース。接続、アイデンティティの管理、ステータスの確認、および管理操作に使用されます。[`doublezerod`](#doublezerod)デーモンと通信します。 +DoubleZeroネットワークと対話するためのコマンドラインインターフェース。接続、ID管理、ステータス確認、管理操作に使用されます。[`doublezerod`](#doublezerod)デーモンと通信します。 ### Config Agent [DZD](#dzd-doublezero-device)上で実行されるソフトウェアエージェントで、デバイス設定を管理します。[Controller](#controller)サービスから設定を読み取り、デバイスに変更を適用します。セットアップについては[Config Agentのインストール](contribute-provisioning.md#step-44-install-config-agent)を参照してください。 @@ -78,99 +78,99 @@ DoubleZeroネットワークとやり取りするためのコマンドライン ## リンク状態 ### アクティベート済み -リンクの通常の運用状態。トラフィックがリンクを通過し、ルーティング決定に参加します。 +リンクの通常の動作状態。トラフィックがリンクを通過し、ルーティング決定に参加します。 ### ソフトドレイン -特定のリンクでトラフィックが抑制されるメンテナンス状態。グレースフルなメンテナンスウィンドウに使用されます。[アクティベート済み](#activated)または[ハードドレイン](#hard-drained)に移行できます。 +特定のリンクでトラフィックが抑制されるメンテナンス状態。計画的なメンテナンスウィンドウに使用されます。[アクティベート済み](#アクティベート済み)または[ハードドレイン](#ハードドレイン)に遷移できます。 ### ハードドレイン -リンクがサービスから完全に除外されるメンテナンス状態。リンクを通過するトラフィックはありません。[アクティベート済み](#activated)に戻る前に[ソフトドレイン](#soft-drained)に移行する必要があります。 +リンクが完全にサービスから除外されるメンテナンス状態。トラフィックはリンクを通過しません。[アクティベート済み](#アクティベート済み)に戻るには、先に[ソフトドレイン](#ソフトドレイン)に遷移する必要があります。 --- ## 組織とトークン ### DZF (DoubleZero Foundation) -DoubleZero Foundationは、DoubleZeroネットワークの開発、分散化、セキュリティ、および普及を支援するために設立された、メンバーを持たないケイマン諸島の非営利財団法人です。 +DoubleZero Foundationは、DoubleZeroネットワークの開発、分散化、セキュリティ、普及を支援するために設立された、会員を持たないケイマン諸島の非営利財団法人です。 ### 2Zトークン -DoubleZeroネットワークのネイティブトークン。バリデーター手数料の支払いに使用され、[コントリビューター](#contributor)への報酬として配布されます。バリデーターはオンチェーンスワッププログラムを通じて2Zで手数料を支払うことができます。[SOLから2Zへのスワップ](Swapping-sol-to-2z.md)を参照してください。 +DoubleZeroネットワークのネイティブトークン。バリデーター手数料の支払いに使用され、[コントリビューター](#contributor)への報酬として分配されます。バリデーターはオンチェーンスワッププログラムを介して2Zで手数料を支払うことができます。[SOLから2Zへのスワップ](Swapping-sol-to-2z.md)を参照してください。 ### コントリビューター -DoubleZeroネットワークに帯域幅とハードウェアを提供するネットワークインフラストラクチャプロバイダー。コントリビューターは[DZD](#dzd-doublezero-device)を運用し、[WAN](#wanリンク)および[DZX](#dzxリンク)リンクを提供し、その貢献に対して[2Z](#2zトークン)トークンインセンティブを受け取ります。開始するには[コントリビュータードキュメント](contribute-overview.md)を参照してください。 +DoubleZeroネットワークに帯域幅とハードウェアを提供するネットワークインフラストラクチャプロバイダー。コントリビューターは[DZD](#dzd-doublezero-device)を運用し、[WAN](#wanリンク)および[DZX](#dzxリンク)リンクを提供し、その貢献に対して[2Z](#2zトークン)トークンのインセンティブを受け取ります。開始するには[コントリビュータードキュメント](contribute-overview.md)を参照してください。 --- ## ネットワーキング概念 ### MTU (Maximum Transmission Unit) -ネットワークリンク上で送信可能な最大パケットサイズ（バイト単位）。DoubleZeroのWANリンクは通常、効率性のためにMTU 9000（ジャンボフレーム）を使用します。 +ネットワークリンクを介して送信できる最大パケットサイズ（バイト単位）。DoubleZeroのWANリンクは通常、効率性のためにMTU 9000（ジャンボフレーム）を使用します。 ### VRF (Virtual Routing and Forwarding) -同一の物理ルーター上に複数の分離されたルーティングテーブルを存在させる技術。コントリビューターは多くの場合、スイッチ管理トラフィックを本番トラフィックから分離するために別の管理VRFを使用します。 +同一の物理ルーター上に複数の分離されたルーティングテーブルを共存させる技術。コントリビューターは通常、スイッチ管理トラフィックを本番トラフィックから分離するために、別の管理VRFを使用します。 ### GRE (Generic Routing Encapsulation) ネットワークパケットをIPパケット内にカプセル化するトンネリングプロトコル。[IBRL](#ibrl-increase-bandwidth-reduce-latency)および[CYOA](#cyoa-choose-your-own-adventure)接続で、ユーザーとDZD間のオーバーレイトンネルを作成するために使用されます。 ### BGP (Border Gateway Protocol) -インターネット上のネットワーク間でルーティング情報を交換するために使用されるルーティングプロトコル。DoubleZeroは内部的にASN 65342でBGPを使用しています。 +インターネット上のネットワーク間でルーティング情報を交換するために使用されるルーティングプロトコル。DoubleZeroは内部的にASN 65342でBGPを使用します。 ### ASN (Autonomous System Number) BGPルーティングのためにネットワークに割り当てられる一意の識別子。すべてのDoubleZeroデバイスは内部BGPプロセスに**ASN 65342**を使用します。 ### ループバックインターフェース -管理およびルーティング目的でルーター/スイッチ上に設定される仮想ネットワークインターフェース。DZDは内部ルーティングにLoopback255（VPNv4）およびLoopback256（IPv4）を使用します。 +管理およびルーティング目的で使用されるルーター/スイッチ上の仮想ネットワークインターフェース。DZDは内部ルーティングにLoopback255（VPNv4）とLoopback256（IPv4）を使用します。 ### CIDR (Classless Inter-Domain Routing) -IPアドレス範囲を指定するための表記法。形式は`IP/prefix-length`で、プレフィックス長はネットワークサイズを示します（例：`/29` = 8アドレス、`/24` = 256アドレス）。 +IPアドレス範囲を指定するための表記法。形式は`IP/プレフィックス長`で、プレフィックス長はネットワークサイズを示します（例：`/29` = 8アドレス、`/24` = 256アドレス）。 ### ジッター -時間の経過に伴うパケットレイテンシの変動。リアルタイムアプリケーションにとって低ジッターは極めて重要です。 +時間経過に伴うパケットレイテンシのばらつき。リアルタイムアプリケーションにとって低ジッターは重要です。 ### RTT (Round-Trip Time) -パケットが送信元から宛先に到達し、戻ってくるまでの時間。デバイス間のネットワークレイテンシの測定に使用されます。 +パケットが送信元から宛先へ移動し、戻ってくるまでの時間。デバイス間のネットワークレイテンシを測定するために使用されます。 ### TWAMP (Two-Way Active Measurement Protocol) -レイテンシやパケットロスなどのネットワークパフォーマンスメトリクスを測定するためのプロトコル。[Telemetry Agent](#telemetry-agent)はTWAMPを使用してDZD間のメトリクスを収集します。 +レイテンシやパケットロスなどのネットワークパフォーマンスメトリクスを測定するためのプロトコル。[Telemetry Agent](#telemetry-agent)はDZD間のメトリクスを収集するためにTWAMPを使用します。 ### IS-IS (Intermediate System to Intermediate System) -DoubleZeroネットワーク内部で使用されるリンクステートルーティングプロトコル。IS-ISメトリクスは[リンクドレイン](#soft-drained)操作中に調整されます。 +DoubleZeroネットワーク内部で使用されるリンクステートルーティングプロトコル。IS-ISメトリクスは[リンクドレイン](#ソフトドレイン)操作時に調整されます。 --- ## ジオロケーション ### ジオロケーション -レイテンシ測定を使用してデバイスの物理的な位置を検証するDoubleZeroサービス。既知の位置のインフラストラクチャ（[DZD](#dzd-doublezero-device)）とターゲットデバイス間の[RTT](#rtt-round-trip-time)測定により、デバイスが基準点から一定の距離内にあることの暗号学的に署名された証明が提供されます。測定のオンチェーン記録は将来のリリースで予定されています。ユーザードキュメントについては[ジオロケーション](geolocation.md)を参照してください。 +レイテンシ測定を使用してデバイスの物理的な位置を検証するDoubleZeroサービス。既知の場所にあるインフラストラクチャ（[DZD](#dzd-doublezero-device)）とターゲットデバイス間の[RTT](#rtt-round-trip-time)測定により、デバイスが基準点から一定の距離内にあることの暗号署名付き証明を提供します。測定のオンチェーン記録は将来のリリースで計画されています。ユーザードキュメントについては[ジオロケーション](geolocation.md)を参照してください。 ### geoProbe -[ジオロケーション](#ジオロケーション)システムにおけるレイテンシ測定の仲介役として機能するベアメタルサーバー。geoProbeは[DZD](#dzd-doublezero-device)から約1ms以内の場所に設置され、親DZDから署名されたLocationOffsetを受信し、[TWAMP](#twamp-two-way-active-measurement-protocol)、署名付きTWAMP、またはICMPエコーを介してターゲットデバイスへの[RTT](#rtt-round-trip-time)を測定します。各geoProbeは[オンチェーン](#onchain)に登録され、1つ以上の親DZDにリンクされています。コントリビュータードキュメントについては[geoProbeのデプロイ](contribute-geolocation.md)を参照してください。 +[ジオロケーション](#ジオロケーション)システムにおけるレイテンシ測定の仲介役として機能するベアメタルサーバー。geoProbeは[DZD](#dzd-doublezero-device)から約1ms以内の場所に配置され、親DZDから署名済みLocationOffsetを受信し、[TWAMP](#twamp-two-way-active-measurement-protocol)、署名済みTWAMP、またはICMPエコーを介してターゲットデバイスへの[RTT](#rtt-round-trip-time)を測定します。各geoProbeは[オンチェーン](#onchain)で登録され、1つ以上の親DZDにリンクされます。コントリビュータードキュメントについては[geoProbeのデプロイ](contribute-geolocation.md)を参照してください。 ### LocationOffset -[DZD](#dzd-doublezero-device)の地理的位置（緯度と経度）およびエンティティ間のレイテンシ関係チェーン（DZD↔Probe または Probe↔Target）を含む署名されたデータ構造。LocationOffsetはEd25519で署名され、測定チェーンを通じてUDP経由で送信されます。複合オフセットには以前の測定への参照が含まれ、監査可能なトレイルを作成します。 +[DZD](#dzd-doublezero-device)の地理的位置（緯度と経度）とエンティティ間のレイテンシ関係のチェーン（DZD↔Probe または Probe↔Target）を含む署名済みデータ構造。LocationOffsetはEd25519で署名され、測定チェーンを通じてUDPで送信されます。複合オフセットには以前の測定への参照が含まれ、監査可能なトレイルを作成します。 --- ## ブロックチェーンと鍵 ### オンチェーン -DoubleZeroの文脈では、オンチェーンとはDoubleZero台帳上に記録されるデータおよび操作を指します。デバイスやリンクの設定が集中管理システムに存在する従来のネットワークとは異なり、DoubleZeroはデバイス登録、リンク設定、テレメトリ送信をオンチェーンに記録し、ネットワーク状態をすべての参加者が透明かつ検証可能な形で利用できるようにします。 +DoubleZeroの文脈では、オンチェーンとはDoubleZero台帳に記録されるデータと操作を指します。デバイスやリンクの設定が集中管理システムに存在する従来のネットワークとは異なり、DoubleZeroはデバイス登録、リンク設定、テレメトリ送信をオンチェーンに記録し、ネットワーク状態をすべての参加者が透過的かつ検証可能にします。 ### サービスキー -CLI操作の認証に使用される暗号鍵ペア。DoubleZeroスマートコントラクトとやり取りするためのコントリビューターのアイデンティティです。`~/.config/solana/id.json`に保存されます。 +CLI操作の認証に使用される暗号鍵ペア。これはDoubleZeroスマートコントラクトと対話するためのコントリビューターIDです。`~/.config/solana/id.json`に保存されます。 ### メトリクスパブリッシャーキー -[Telemetry Agent](#telemetry-agent)がブロックチェーンへのメトリクス送信に署名するために使用する暗号鍵ペア。セキュリティ分離のためにサービスキーとは分離されています。`~/.config/doublezero/metrics-publisher.json`に保存されます。 +[Telemetry Agent](#telemetry-agent)がブロックチェーンへのメトリクス送信に署名するために使用する暗号鍵ペア。セキュリティ分離のためにサービスキーとは別に管理されます。`~/.config/doublezero/metrics-publisher.json`に保存されます。 ### リワードマネージャーキー -コントリビューターの報酬の支払い先を制御する暗号鍵ペア。受取ウォレットリストの変更に署名しますが、報酬自体を保持することはありません。[DZF](#dzf-doublezero-foundation)によってコントリビューターの[サービスキー](#サービスキー)に対して登録されます。[報酬管理](contribute-rewards.md)を参照してください。 +コントリビューターの報酬の支払先を制御する暗号鍵ペア。受取ウォレットリストの変更に署名しますが、報酬自体を保持することはありません。[サービスキー](#サービスキー)とは別に管理されます。コントリビューターリポジトリの[報酬管理](https://github.com/malbeclabs/contributors#rewards-management)を参照してください。 --- ## ハードウェアとソフトウェア ### EOS (Extensible Operating System) -DZDスイッチ上で動作するAristaのネットワークオペレーティングシステム。コントリビューターは[Config Agent](#config-agent)と[Telemetry Agent](#telemetry-agent)をEOS拡張としてインストールします。 +DZDスイッチ上で動作するAristaのネットワークオペレーティングシステム。コントリビューターはEOS拡張機能として[Config Agent](#config-agent)と[Telemetry Agent](#telemetry-agent)をインストールします。 -### EOS拡張 +### EOS拡張機能 Arista EOSスイッチにインストールできるソフトウェアパッケージ。DZエージェントは`.rpm`ファイルとして配布され、`extension`コマンドを介してインストールされます。 \ No newline at end of file diff --git a/docs/glossary.ko.md b/docs/glossary.ko.md index a862080..bc82d5b 100644 --- a/docs/glossary.ko.md +++ b/docs/glossary.ko.md @@ -1,26 +1,26 @@ --- -description: 문서 전반에서 사용되는 DoubleZero 전용 용어 정의. +description: 문서 전반에서 사용되는 DoubleZero 관련 용어 정의. --- # 용어집 -이 페이지는 문서 전반에서 사용되는 DoubleZero 전용 용어를 정의합니다. +이 페이지에서는 문서 전반에서 사용되는 DoubleZero 관련 용어를 정의합니다. --- ## 네트워크 인프라 ### DZD (DoubleZero Device) -DoubleZero 링크를 종단하고 DoubleZero Agent 소프트웨어를 실행하는 물리적 네트워크 스위칭 하드웨어입니다. DZD는 데이터 센터에 배포되며 라우팅, 패킷 처리 및 사용자 연결 서비스를 제공합니다. 각 DZD는 특정 [하드웨어 사양](contribute.md#dzd-network-hardware)을 요구하며 [Config Agent](#config-agent)와 [Telemetry Agent](#telemetry-agent)를 모두 실행합니다. +DoubleZero 링크를 종단하고 DoubleZero Agent 소프트웨어를 실행하는 물리적 네트워크 스위칭 하드웨어입니다. DZD는 데이터 센터에 배치되며 라우팅, 패킷 처리 및 사용자 연결 서비스를 제공합니다. 각 DZD는 특정 [하드웨어 사양](contribute.md#dzd-network-hardware)을 요구하며, [Config Agent](#config-agent)와 [Telemetry Agent](#telemetry-agent)를 모두 실행합니다. ### DZX (DoubleZero Exchange) -서로 다른 [기여자](#contributor) 링크가 브리징되는 메시 네트워크의 상호 연결 지점입니다. DZX는 네트워크 교차가 발생하는 주요 대도시 지역(예: NYC, LON, TYO)에 위치합니다. 네트워크 기여자는 가장 가까운 DZX에서 자신의 링크를 더 넓은 DoubleZero 메시에 크로스커넥트해야 합니다. 인터넷 교환소(IX)와 유사한 개념입니다. +서로 다른 [기여자](#contributor) 링크가 브리지되는 메시 네트워크의 상호 연결 지점입니다. DZX는 네트워크 교차가 발생하는 주요 대도시 지역(예: NYC, LON, TYO)에 위치합니다. 네트워크 기여자는 가장 가까운 DZX에서 자신의 링크를 더 넓은 DoubleZero 메시에 크로스 커넥트해야 합니다. Internet Exchange(IX)와 유사한 개념입니다. ### WAN Link **동일한** 기여자가 운영하는 두 [DZD](#dzd-doublezero-device) 간의 광역 네트워크 링크입니다. WAN 링크는 단일 기여자의 인프라 내에서 백본 연결을 제공합니다. ### DZX Link -[DZX](#dzx-doublezero-exchange)에서 설정된, **서로 다른** 기여자가 운영하는 [DZD](#dzd-doublezero-device) 간의 링크입니다. DZX 링크는 양측의 명시적인 수락이 필요합니다. +[DZX](#dzx-doublezero-exchange)에서 수립되는 **서로 다른** 기여자가 운영하는 [DZD](#dzd-doublezero-device) 간의 링크입니다. DZX 링크는 양 당사자의 명시적 수락이 필요합니다. ### DZ Prefix 오버레이 네트워크 주소 지정을 위해 [DZD](#dzd-doublezero-device)에 할당된 CIDR 형식의 IP 주소 할당입니다. [디바이스 생성](contribute-provisioning.md#step-32-create-your-device-onchain) 시 `--dz-prefixes` 매개변수를 사용하여 지정합니다. @@ -30,45 +30,45 @@ DoubleZero 링크를 종단하고 DoubleZero Agent 소프트웨어를 실행하 ## 디바이스 유형 ### Edge Device -DoubleZero 네트워크에 대한 사용자 연결을 제공하는 [DZD](#dzd-doublezero-device)입니다. Edge 디바이스는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스를 활용하여 사용자(검증자, RPC 운영자)를 종단하고 네트워크에 연결합니다. +DoubleZero 네트워크에 대한 사용자 연결을 제공하는 [DZD](#dzd-doublezero-device)입니다. Edge 디바이스는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스를 활용하여 사용자(밸리데이터, RPC 운영자)를 종단하고 네트워크에 연결합니다. ### Transit Device -DoubleZero 네트워크 내에서 백본 연결을 제공하는 [DZD](#dzd-doublezero-device)입니다. Transit 디바이스는 DZD 간에 트래픽을 이동시키지만 사용자 연결을 직접 종단하지는 않습니다. +DoubleZero 네트워크 내에서 백본 연결을 제공하는 [DZD](#dzd-doublezero-device)입니다. Transit 디바이스는 DZD 간 트래픽을 이동시키지만 사용자 연결을 직접 종단하지는 않습니다. ### Hybrid Device -[Edge](#edge-device)와 [Transit](#transit-device) 기능을 모두 결합하여 사용자 연결과 백본 라우팅을 모두 제공하는 [DZD](#dzd-doublezero-device)입니다. +[Edge](#edge-device)와 [Transit](#transit-device) 기능을 모두 결합한 [DZD](#dzd-doublezero-device)로, 사용자 연결과 백본 라우팅을 모두 제공합니다. --- -## 연결성 +## 연결 ### CYOA (Choose Your Own Adventure) -[기여자](#contributor)가 사용자가 DoubleZero 네트워크에 연결할 수 있는 연결 옵션을 등록할 수 있게 해주는 인터페이스 유형입니다. CYOA 인터페이스에는 [DIA](#dia-direct-internet-access), GRE 터널, 프라이빗 피어링 등 다양한 방법이 포함됩니다. 구성 세부 사항은 [CYOA 인터페이스 생성](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)을 참조하세요. +[기여자](#contributor)가 사용자가 DoubleZero 네트워크에 연결할 수 있는 연결 옵션을 등록할 수 있도록 하는 인터페이스 유형입니다. CYOA 인터페이스에는 [DIA](#dia-direct-internet-access), GRE 터널, 프라이빗 피어링 등 다양한 방법이 포함됩니다. 구성 세부 사항은 [CYOA 인터페이스 생성](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)을 참조하세요. ### DIA (Direct Internet Access) -공용 인터넷을 통해 제공되는 연결에 대한 표준 네트워킹 용어입니다. DoubleZero에서 DIA는 사용자(검증자, RPC 운영자)가 기존 인터넷 연결을 통해 [DZD](#dzd-doublezero-device)에 연결하는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스 유형입니다. +공용 인터넷을 통해 제공되는 연결에 대한 표준 네트워킹 용어입니다. DoubleZero에서 DIA는 사용자(밸리데이터, RPC 운영자)가 기존 인터넷 연결을 통해 [DZD](#dzd-doublezero-device)에 연결하는 [CYOA](#cyoa-choose-your-own-adventure) 인터페이스 유형입니다. ### IBRL (Increase Bandwidth Reduce Latency) -검증자 및 RPC 노드가 블록체인 클라이언트를 재시작하지 않고 DoubleZero에 연결할 수 있게 해주는 연결 모드입니다. IBRL은 기존 공용 IP 주소를 사용하며 가장 가까운 [DZD](#dzd-doublezero-device)로의 오버레이 터널을 설정합니다. 설정 지침은 [Mainnet-Beta 연결](DZ%20Mainnet-beta%20Connection.md)을 참조하세요. +밸리데이터와 RPC 노드가 블록체인 클라이언트를 재시작하지 않고 DoubleZero에 연결할 수 있는 연결 모드입니다. IBRL은 기존 공용 IP 주소를 사용하고 가장 가까운 [DZD](#dzd-doublezero-device)에 오버레이 터널을 수립합니다. 설정 방법은 [Mainnet-Beta 연결](DZ%20Mainnet-beta%20Connection.md)을 참조하세요. ### Multicast -DoubleZero에서 지원하는 일대다 패킷 전달 방법입니다. Multicast 모드에는 두 가지 역할이 있습니다: **퍼블리셔**(네트워크를 통해 패킷 전송)와 **구독자**(퍼블리셔로부터 패킷 수신). 개발 팀에서 효율적인 데이터 배포를 위해 사용합니다. 연결 세부 사항은 [기타 Multicast 연결](Other%20Multicast%20Connection.md)을 참조하세요. +DoubleZero가 지원하는 일대다 패킷 전달 방식입니다. Multicast 모드에는 **publisher**(네트워크 전체에 패킷을 전송)와 **subscriber**(publisher로부터 패킷을 수신)의 두 가지 역할이 있습니다. 개발 팀이 효율적인 데이터 배포에 사용합니다. 연결 세부 사항은 [기타 Multicast 연결](Other%20Multicast%20Connection.md)을 참조하세요. --- ## 소프트웨어 구성 요소 ### doublezerod -사용자 서버(검증자, RPC 노드)에서 실행되는 DoubleZero 데몬 서비스입니다. DoubleZero 네트워크에 대한 연결을 관리하고, 터널 설정을 처리하며, [DZD](#dzd-doublezero-device)에 대한 연결을 유지합니다. systemd를 통해 구성되며 [`doublezero`](#doublezero-cli) CLI를 통해 제어됩니다. +사용자 서버(밸리데이터, RPC 노드)에서 실행되는 DoubleZero 데몬 서비스입니다. DoubleZero 네트워크 연결을 관리하고, 터널 수립을 처리하며, [DZD](#dzd-doublezero-device)와의 연결을 유지합니다. systemd를 통해 구성되고 [`doublezero`](#doublezero-cli) CLI를 통해 제어됩니다. ### doublezero (CLI) -DoubleZero 네트워크와 상호작용하기 위한 명령줄 인터페이스입니다. 연결, ID 관리, 상태 확인 및 관리 작업에 사용됩니다. [`doublezerod`](#doublezerod) 데몬과 통신합니다. +DoubleZero 네트워크와 상호 작용하기 위한 명령줄 인터페이스입니다. 연결, ID 관리, 상태 확인 및 관리 작업에 사용됩니다. [`doublezerod`](#doublezerod) 데몬과 통신합니다. ### Config Agent -디바이스 구성을 관리하는 [DZD](#dzd-doublezero-device)에서 실행되는 소프트웨어 에이전트입니다. [Controller](#controller) 서비스에서 구성을 읽어 디바이스에 변경 사항을 적용합니다. 설정은 [Config Agent 설치](contribute-provisioning.md#step-44-install-config-agent)를 참조하세요. +[DZD](#dzd-doublezero-device)에서 실행되며 디바이스 구성을 관리하는 소프트웨어 에이전트입니다. [Controller](#controller) 서비스에서 구성을 읽고 디바이스에 변경 사항을 적용합니다. 설정 방법은 [Config Agent 설치](contribute-provisioning.md#step-44-install-config-agent)를 참조하세요. ### Telemetry Agent -성능 메트릭(지연 시간, 지터, 패킷 손실)을 수집하고 DoubleZero 원장에 제출하는 [DZD](#dzd-doublezero-device)에서 실행되는 소프트웨어 에이전트입니다. 설정은 [Telemetry Agent 설치](contribute-provisioning.md#step-45-install-telemetry-agent)를 참조하세요. +[DZD](#dzd-doublezero-device)에서 실행되며 성능 메트릭(지연 시간, 지터, 패킷 손실)을 수집하고 DoubleZero 원장에 제출하는 소프트웨어 에이전트입니다. 설정 방법은 [Telemetry Agent 설치](contribute-provisioning.md#step-45-install-telemetry-agent)를 참조하세요. ### Controller [DZD](#dzd-doublezero-device) 에이전트에 구성을 제공하는 서비스입니다. Controller는 DoubleZero 원장의 [온체인](#onchain) 상태에서 디바이스 구성을 도출합니다. @@ -81,45 +81,45 @@ DoubleZero 네트워크와 상호작용하기 위한 명령줄 인터페이스 링크의 정상 운영 상태입니다. 트래픽이 링크를 통해 흐르며 라우팅 결정에 참여합니다. ### Soft-Drained -특정 링크에서 트래픽이 억제되는 유지보수 상태입니다. 원활한 유지보수 기간에 사용됩니다. [activated](#activated) 또는 [hard-drained](#hard-drained)로 전환할 수 있습니다. +특정 링크에서 트래픽이 비권장되는 유지보수 상태입니다. 원활한 유지보수 기간에 사용됩니다. [activated](#activated) 또는 [hard-drained](#hard-drained)로 전환할 수 있습니다. ### Hard-Drained -링크가 서비스에서 완전히 제거되는 유지보수 상태입니다. 링크를 통해 트래픽이 흐르지 않습니다. [activated](#activated)로 돌아가려면 먼저 [soft-drained](#soft-drained)로 전환해야 합니다. +링크가 서비스에서 완전히 제거된 유지보수 상태입니다. 링크를 통해 트래픽이 흐르지 않습니다. [activated](#activated)로 돌아가려면 먼저 [soft-drained](#soft-drained)로 전환해야 합니다. --- ## 조직 및 토큰 ### DZF (DoubleZero Foundation) -DoubleZero Foundation은 DoubleZero 네트워크의 개발, 탈중앙화, 보안 및 채택을 지원하기 위해 설립된 회원 없는 비영리 케이맨 제도 재단 법인입니다. +DoubleZero Foundation은 DoubleZero 네트워크의 개발, 탈중앙화, 보안 및 채택을 지원하기 위해 설립된 회원 없는 비영리 케이맨 제도 재단법인입니다. ### 2Z Token -DoubleZero 네트워크의 네이티브 토큰입니다. 검증자 수수료 지불에 사용되며 [기여자](#contributor)에게 보상으로 배분됩니다. 검증자는 온체인 스왑 프로그램을 통해 2Z로 수수료를 지불할 수 있습니다. [SOL을 2Z로 스왑하기](Swapping-sol-to-2z.md)를 참조하세요. +DoubleZero 네트워크의 네이티브 토큰입니다. 밸리데이터 수수료 지불에 사용되며 [기여자](#contributor)에게 보상으로 분배됩니다. 밸리데이터는 온체인 스왑 프로그램을 통해 2Z로 수수료를 지불할 수 있습니다. [SOL을 2Z로 스왑하기](Swapping-sol-to-2z.md)를 참조하세요. ### Contributor -DoubleZero 네트워크에 대역폭과 하드웨어를 기여하는 네트워크 인프라 제공자입니다. 기여자는 [DZD](#dzd-doublezero-device)를 운영하고, [WAN](#wan-link) 및 [DZX](#dzx-link) 링크를 제공하며, 기여에 대한 [2Z](#2z-token) 토큰 인센티브를 받습니다. 시작하려면 [기여자 문서](contribute-overview.md)를 참조하세요. +DoubleZero 네트워크에 대역폭과 하드웨어를 기여하는 네트워크 인프라 제공자입니다. 기여자는 [DZD](#dzd-doublezero-device)를 운영하고, [WAN](#wan-link) 및 [DZX](#dzx-link) 링크를 제공하며, 기여에 대해 [2Z](#2z-token) 토큰 인센티브를 받습니다. 시작하려면 [기여자 문서](contribute-overview.md)를 참조하세요. --- ## 네트워킹 개념 ### MTU (Maximum Transmission Unit) -네트워크 링크를 통해 전송할 수 있는 최대 패킷 크기(바이트)입니다. DoubleZero WAN 링크는 효율성을 위해 일반적으로 MTU 9000(점보 프레임)을 사용합니다. +네트워크 링크를 통해 전송할 수 있는 최대 패킷 크기(바이트 단위)입니다. DoubleZero WAN 링크는 효율성을 위해 일반적으로 MTU 9000(점보 프레임)을 사용합니다. ### VRF (Virtual Routing and Forwarding) -동일한 물리적 라우터에 여러 개의 격리된 라우팅 테이블이 존재할 수 있게 해주는 기술입니다. 기여자는 종종 별도의 관리 VRF를 사용하여 스위치 관리 트래픽을 프로덕션 트래픽에서 격리합니다. +동일한 물리적 라우터에 여러 격리된 라우팅 테이블이 존재할 수 있게 하는 기술입니다. 기여자는 종종 스위치 관리 트래픽을 프로덕션 트래픽으로부터 격리하기 위해 별도의 관리 VRF를 사용합니다. ### GRE (Generic Routing Encapsulation) -네트워크 패킷을 IP 패킷 내부에 캡슐화하는 터널링 프로토콜입니다. [IBRL](#ibrl-increase-bandwidth-reduce-latency) 및 [CYOA](#cyoa-choose-your-own-adventure) 연결에서 사용자와 DZD 간에 오버레이 터널을 생성하는 데 사용됩니다. +네트워크 패킷을 IP 패킷 내에 캡슐화하는 터널링 프로토콜입니다. [IBRL](#ibrl-increase-bandwidth-reduce-latency) 및 [CYOA](#cyoa-choose-your-own-adventure) 연결에서 사용자와 DZD 간의 오버레이 터널을 생성하는 데 사용됩니다. ### BGP (Border Gateway Protocol) -인터넷 상의 네트워크 간 라우팅 정보를 교환하는 데 사용되는 라우팅 프로토콜입니다. DoubleZero는 내부적으로 ASN 65342를 사용하여 BGP를 사용합니다. +인터넷상의 네트워크 간 라우팅 정보를 교환하는 데 사용되는 라우팅 프로토콜입니다. DoubleZero는 내부적으로 ASN 65342를 사용하여 BGP를 운용합니다. ### ASN (Autonomous System Number) BGP 라우팅을 위해 네트워크에 할당된 고유 식별자입니다. 모든 DoubleZero 디바이스는 내부 BGP 프로세스에 **ASN 65342**를 사용합니다. ### Loopback Interface -관리 및 라우팅 목적으로 라우터/스위치에서 사용되는 가상 네트워크 인터페이스입니다. DZD는 내부 라우팅을 위해 Loopback255(VPNv4)와 Loopback256(IPv4)을 사용합니다. +관리 및 라우팅 목적으로 사용되는 라우터/스위치의 가상 네트워크 인터페이스입니다. DZD는 내부 라우팅을 위해 Loopback255(VPNv4)와 Loopback256(IPv4)을 사용합니다. ### CIDR (Classless Inter-Domain Routing) IP 주소 범위를 지정하기 위한 표기법입니다. 형식은 `IP/prefix-length`이며, 프리픽스 길이는 네트워크 크기를 나타냅니다(예: `/29` = 8개 주소, `/24` = 256개 주소). @@ -128,23 +128,23 @@ IP 주소 범위를 지정하기 위한 표기법입니다. 형식은 `IP/prefix 시간에 따른 패킷 지연 시간의 변동입니다. 낮은 지터는 실시간 애플리케이션에 매우 중요합니다. ### RTT (Round-Trip Time) -패킷이 출발지에서 목적지까지 이동하고 돌아오는 데 걸리는 시간입니다. 디바이스 간 네트워크 지연 시간을 측정하는 데 사용됩니다. +패킷이 출발지에서 목적지까지 이동한 후 다시 돌아오는 데 걸리는 시간입니다. 디바이스 간 네트워크 지연 시간을 측정하는 데 사용됩니다. ### TWAMP (Two-Way Active Measurement Protocol) -지연 시간 및 패킷 손실과 같은 네트워크 성능 메트릭을 측정하기 위한 프로토콜입니다. [Telemetry Agent](#telemetry-agent)는 TWAMP를 사용하여 DZD 간의 메트릭을 수집합니다. +지연 시간 및 패킷 손실과 같은 네트워크 성능 메트릭을 측정하기 위한 프로토콜입니다. [Telemetry Agent](#telemetry-agent)는 DZD 간 메트릭을 수집하기 위해 TWAMP를 사용합니다. ### IS-IS (Intermediate System to Intermediate System) DoubleZero 네트워크 내부에서 사용되는 링크 상태 라우팅 프로토콜입니다. IS-IS 메트릭은 [링크 드레이닝](#soft-drained) 작업 중에 조정됩니다. --- -## 지리적 위치 확인 +## 위치 확인 ### Geolocation -지연 시간 측정을 사용하여 디바이스의 물리적 위치를 검증하는 DoubleZero 서비스입니다. 알려진 위치의 인프라([DZD](#dzd-doublezero-device))와 대상 디바이스 간의 [RTT](#rtt-round-trip-time) 측정은 디바이스가 기준점의 특정 거리 내에 있다는 암호학적으로 서명된 증명을 제공합니다. 측정의 온체인 기록은 향후 릴리스에 계획되어 있습니다. 사용자 문서는 [Geolocation](geolocation.md)을 참조하세요. +지연 시간 측정을 사용하여 디바이스의 물리적 위치를 검증하는 DoubleZero 서비스입니다. 알려진 위치의 인프라([DZD](#dzd-doublezero-device))와 대상 디바이스 간의 [RTT](#rtt-round-trip-time) 측정은 디바이스가 기준점으로부터 특정 거리 내에 있다는 암호학적으로 서명된 증명을 제공합니다. 측정값의 온체인 기록은 향후 릴리스에서 계획되어 있습니다. 사용자 문서는 [Geolocation](geolocation.md)을 참조하세요. ### geoProbe -[Geolocation](#geolocation) 시스템에서 지연 시간 측정의 중개 역할을 하는 베어메탈 서버입니다. geoProbe는 [DZD](#dzd-doublezero-device)에서 ~1ms 이내에 위치하며, 상위 DZD로부터 서명된 LocationOffset을 수신하고, [TWAMP](#twamp-two-way-active-measurement-protocol), 서명된 TWAMP 또는 ICMP echo를 통해 대상 디바이스까지의 [RTT](#rtt-round-trip-time)를 측정합니다. 각 geoProbe는 [온체인](#onchain)에 등록되며 하나 이상의 상위 DZD에 연결됩니다. 기여자 문서는 [Geoprobe 배포](contribute-geolocation.md)를 참조하세요. +[Geolocation](#geolocation) 시스템에서 지연 시간 측정을 위한 중계 역할을 하는 베어 메탈 서버입니다. geoProbe는 [DZD](#dzd-doublezero-device)로부터 ~1ms 이내에 위치하며, 상위 DZD로부터 서명된 LocationOffset을 수신하고, [TWAMP](#twamp-two-way-active-measurement-protocol), 서명된 TWAMP 또는 ICMP echo를 통해 대상 디바이스까지의 [RTT](#rtt-round-trip-time)를 측정합니다. 각 geoProbe는 [온체인](#onchain)에 등록되며 하나 이상의 상위 DZD에 연결됩니다. 기여자 문서는 [Geoprobe 배포](contribute-geolocation.md)를 참조하세요. ### LocationOffset [DZD](#dzd-doublezero-device)의 지리적 위치(위도 및 경도)와 엔티티 간(DZD↔Probe 또는 Probe↔Target)의 지연 시간 관계 체인을 포함하는 서명된 데이터 구조입니다. LocationOffset은 Ed25519로 서명되며 측정 체인을 통해 UDP로 전송됩니다. 복합 오프셋은 이전 측정에 대한 참조를 포함하여 감사 가능한 추적 경로를 생성합니다. @@ -154,23 +154,23 @@ DoubleZero 네트워크 내부에서 사용되는 링크 상태 라우팅 프로 ## 블록체인 및 키 ### Onchain -DoubleZero 맥락에서 온체인은 DoubleZero 원장에 기록된 데이터 및 작업을 의미합니다. 디바이스 및 링크 구성이 중앙 집중식 관리 시스템에 존재하는 기존 네트워크와 달리, DoubleZero는 디바이스 등록, 링크 구성 및 텔레메트리 제출을 온체인에 기록하여 네트워크 상태를 모든 참여자가 투명하고 검증 가능하게 합니다. +DoubleZero 맥락에서 온체인은 DoubleZero 원장에 기록된 데이터와 작업을 의미합니다. 디바이스 및 링크 구성이 중앙 집중식 관리 시스템에 존재하는 기존 네트워크와 달리, DoubleZero는 디바이스 등록, 링크 구성 및 텔레메트리 제출을 온체인에 기록하여 모든 참여자가 네트워크 상태를 투명하고 검증 가능하게 합니다. ### Service Key -CLI 작업을 인증하는 데 사용되는 암호화 키 쌍입니다. DoubleZero 스마트 컨트랙트와 상호작용하기 위한 기여자 ID입니다. `~/.config/solana/id.json`에 저장됩니다. +CLI 작업을 인증하는 데 사용되는 암호화 키쌍입니다. DoubleZero 스마트 컨트랙트와 상호 작용하기 위한 기여자 ID입니다. `~/.config/solana/id.json`에 저장됩니다. ### Metrics Publisher Key -[Telemetry Agent](#telemetry-agent)가 블록체인에 대한 메트릭 제출에 서명하는 데 사용하는 암호화 키 쌍입니다. 보안 격리를 위해 서비스 키와 분리되어 있습니다. `~/.config/doublezero/metrics-publisher.json`에 저장됩니다. +[Telemetry Agent](#telemetry-agent)가 블록체인에 메트릭 제출에 서명하는 데 사용하는 암호화 키쌍입니다. 보안 격리를 위해 Service Key와 분리되어 있습니다. `~/.config/doublezero/metrics-publisher.json`에 저장됩니다. ### Rewards Manager Key -기여자의 보상이 지급되는 위치를 제어하는 암호화 키 쌍입니다. 수신 지갑 목록의 변경에 서명하지만 보상 자체를 보유하지는 않습니다. [DZF](#dzf-doublezero-foundation)에 의해 기여자의 [Service Key](#service-key)에 대해 등록됩니다. [보상 관리](contribute-rewards.md)를 참조하세요. +기여자의 보상이 지급되는 위치를 제어하는 암호화 키쌍입니다. 수신 지갑 목록의 변경에 서명하지만 보상 자체를 보유하지는 않습니다. [Service Key](#service-key)와 분리하여 보관합니다. 기여자 리포지토리의 [보상 관리](https://github.com/malbeclabs/contributors#rewards-management)를 참조하세요. --- ## 하드웨어 및 소프트웨어 ### EOS (Extensible Operating System) -DZD 스위치에서 실행되는 Arista의 네트워크 운영 체제입니다. 기여자는 [Config Agent](#config-agent) 및 [Telemetry Agent](#telemetry-agent)를 EOS 확장으로 설치합니다. +DZD 스위치에서 실행되는 Arista의 네트워크 운영 체제입니다. 기여자는 [Config Agent](#config-agent)와 [Telemetry Agent](#telemetry-agent)를 EOS 확장으로 설치합니다. ### EOS Extension Arista EOS 스위치에 설치할 수 있는 소프트웨어 패키지입니다. DZ 에이전트는 `.rpm` 파일로 배포되며 `extension` 명령을 통해 설치됩니다. \ No newline at end of file diff --git a/docs/glossary.pt.md b/docs/glossary.pt.md index dd93760..25a9855 100644 --- a/docs/glossary.pt.md +++ b/docs/glossary.pt.md @@ -1,42 +1,42 @@ --- -description: Definições da terminologia específica do DoubleZero utilizada ao longo da documentação. +description: Definições da terminologia específica do DoubleZero usada ao longo da documentação. --- # Glossário -Esta página define a terminologia específica do DoubleZero utilizada ao longo da documentação. +Esta página define a terminologia específica do DoubleZero usada ao longo da documentação. --- ## Infraestrutura de Rede ### DZD (DoubleZero Device) -O hardware físico de comutação de rede que termina os links DoubleZero e executa o software DoubleZero Agent. Os DZDs são implantados em data centers e fornecem serviços de roteamento, processamento de pacotes e conectividade de usuários. Cada DZD requer [especificações de hardware](contribute.md#dzd-network-hardware) específicas e executa tanto o [Config Agent](#config-agent) quanto o [Telemetry Agent](#telemetry-agent). +O hardware físico de comutação de rede que termina os links do DoubleZero e executa o software DoubleZero Agent. Os DZDs são implantados em data centers e fornecem serviços de roteamento, processamento de pacotes e conectividade de usuários. Cada DZD requer [especificações de hardware](contribute.md#dzd-network-hardware) específicas e executa tanto o [Config Agent](#config-agent) quanto o [Telemetry Agent](#telemetry-agent). ### DZX (DoubleZero Exchange) -Pontos de interconexão na rede mesh onde os links de diferentes [contribuidores](#contributor) são interligados. Os DZXs estão localizados em grandes áreas metropolitanas (ex.: NYC, LON, TYO) onde ocorrem interseções de rede. Os contribuidores da rede devem fazer a conexão cruzada de seus links na malha mais ampla do DoubleZero no DZX mais próximo. Conceito similar a um Internet Exchange (IX). +Pontos de interconexão na rede mesh onde links de diferentes [contribuidores](#contributor) são interligados. Os DZXs estão localizados em grandes áreas metropolitanas (por exemplo, NYC, LON, TYO) onde ocorrem interseções de rede. Os contribuidores de rede devem fazer a conexão cruzada de seus links na mesh mais ampla do DoubleZero no DZX mais próximo. Conceito semelhante a um Internet Exchange (IX). ### WAN Link -Um link de Rede de Longa Distância (Wide Area Network) entre dois [DZDs](#dzd-doublezero-device) operados pelo **mesmo** contribuidor. Os links WAN fornecem conectividade de backbone dentro da infraestrutura de um único contribuidor. +Um link de Rede de Longa Distância (Wide Area Network) entre dois [DZDs](#dzd-doublezero-device) operados pelo **mesmo** contribuidor. Os WAN links fornecem conectividade de backbone dentro da infraestrutura de um único contribuidor. ### DZX Link -Um link entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, estabelecido em um [DZX](#dzx-doublezero-exchange). Os links DZX requerem aceitação explícita de ambas as partes. +Um link entre [DZDs](#dzd-doublezero-device) operados por contribuidores **diferentes**, estabelecido em um [DZX](#dzx-doublezero-exchange). Os DZX links exigem aceitação explícita de ambas as partes. ### DZ Prefix -Alocações de endereços IP no formato CIDR atribuídas a um [DZD](#dzd-doublezero-device) para endereçamento da rede overlay. Especificado durante a [criação do dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando o parâmetro `--dz-prefixes`. +Alocações de endereços IP em formato CIDR atribuídas a um [DZD](#dzd-doublezero-device) para endereçamento de rede overlay. Especificadas durante a [criação do dispositivo](contribute-provisioning.md#step-32-create-your-device-onchain) usando o parâmetro `--dz-prefixes`. --- -## Tipos de Dispositivos +## Tipos de Dispositivo ### Edge Device -Um [DZD](#dzd-doublezero-device) que fornece conectividade de usuários à rede DoubleZero. Os dispositivos edge utilizam interfaces [CYOA](#cyoa-choose-your-own-adventure) para terminar usuários (validadores, operadores RPC) e conectá-los à rede. +Um [DZD](#dzd-doublezero-device) que fornece conectividade de usuário à rede DoubleZero. Os dispositivos edge utilizam interfaces [CYOA](#cyoa-choose-your-own-adventure) para terminar usuários (validadores, operadores RPC) e conectá-los à rede. ### Transit Device Um [DZD](#dzd-doublezero-device) que fornece conectividade de backbone dentro da rede DoubleZero. Os dispositivos transit movem tráfego entre DZDs, mas não terminam conexões de usuários diretamente. ### Hybrid Device -Um [DZD](#dzd-doublezero-device) que combina as funcionalidades de [edge](#edge-device) e [transit](#transit-device), fornecendo tanto conectividade de usuários quanto roteamento de backbone. +Um [DZD](#dzd-doublezero-device) que combina as funcionalidades de [edge](#edge-device) e [transit](#transit-device), fornecendo tanto conectividade de usuário quanto roteamento de backbone. --- @@ -49,23 +49,23 @@ Tipos de interface que permitem aos [contribuidores](#contributor) registrar op Um termo padrão de redes para conectividade fornecida pela internet pública. No DoubleZero, DIA é um tipo de interface [CYOA](#cyoa-choose-your-own-adventure) onde os usuários (validadores, operadores RPC) se conectam a um [DZD](#dzd-doublezero-device) através de sua conexão de internet existente. ### IBRL (Increase Bandwidth Reduce Latency) -Um modo de conexão que permite que validadores e nós RPC se conectem ao DoubleZero sem reiniciar seus clientes blockchain. O IBRL utiliza o endereço IP público existente e estabelece um túnel overlay para o [DZD](#dzd-doublezero-device) mais próximo. Consulte [Conexão Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instruções de configuração. +Um modo de conexão que permite que validadores e nós RPC se conectem ao DoubleZero sem reiniciar seus clientes blockchain. O IBRL usa o endereço IP público existente e estabelece um túnel overlay para o [DZD](#dzd-doublezero-device) mais próximo. Consulte [Conexão Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md) para instruções de configuração. ### Multicast -Um método de entrega de pacotes de um-para-muitos suportado pelo DoubleZero. O modo multicast possui dois papéis: **publisher** (envia pacotes pela rede) e **subscriber** (recebe pacotes do publisher). Utilizado por equipes de desenvolvimento para distribuição eficiente de dados. Consulte [Outra Conexão Multicast](Other%20Multicast%20Connection.md) para detalhes de conexão. +Um método de entrega de pacotes de um para muitos suportado pelo DoubleZero. O modo multicast tem duas funções: **publisher** (envia pacotes pela rede) e **subscriber** (recebe pacotes do publisher). Usado por equipes de desenvolvimento para distribuição eficiente de dados. Consulte [Outra Conexão Multicast](Other%20Multicast%20Connection.md) para detalhes de conexão. --- ## Componentes de Software ### doublezerod -O serviço daemon do DoubleZero que é executado nos servidores dos usuários (validadores, nós RPC). Ele gerencia a conexão com a rede DoubleZero, lida com o estabelecimento de túneis e mantém a conectividade com os [DZDs](#dzd-doublezero-device). Configurado via systemd e controlado através da CLI [`doublezero`](#doublezero-cli). +O serviço daemon do DoubleZero que é executado nos servidores dos usuários (validadores, nós RPC). Ele gerencia a conexão com a rede DoubleZero, lida com o estabelecimento de túneis e mantém a conectividade com os [DZDs](#dzd-doublezero-device). Configurado via systemd e controlado através do CLI [`doublezero`](#doublezero-cli). ### doublezero (CLI) -A interface de linha de comando para interagir com a rede DoubleZero. Utilizada para conectar, gerenciar identidades, verificar status e operações administrativas. Comunica-se com o daemon [`doublezerod`](#doublezerod). +A interface de linha de comando para interagir com a rede DoubleZero. Usada para conectar, gerenciar identidades, verificar status e operações administrativas. Comunica-se com o daemon [`doublezerod`](#doublezerod). ### Config Agent -Agente de software executado nos [DZDs](#dzd-doublezero-device) que gerencia a configuração do dispositivo. Lê a configuração do serviço [Controller](#controller) e aplica as alterações no dispositivo. Consulte [Instalação do Config Agent](contribute-provisioning.md#step-44-install-config-agent) para configuração. +Agente de software executado nos [DZDs](#dzd-doublezero-device) que gerencia a configuração do dispositivo. Lê a configuração do serviço [Controller](#controller) e aplica as alterações ao dispositivo. Consulte [Instalação do Config Agent](contribute-provisioning.md#step-44-install-config-agent) para configuração. ### Telemetry Agent Agente de software executado nos [DZDs](#dzd-doublezero-device) que coleta métricas de desempenho (latência, jitter, perda de pacotes) e as submete ao ledger do DoubleZero. Consulte [Instalação do Telemetry Agent](contribute-provisioning.md#step-45-install-telemetry-agent) para configuração. @@ -75,26 +75,26 @@ Um serviço que fornece configuração aos agentes dos [DZDs](#dzd-doublezero-de --- -## Estados dos Links +## Estados de Link ### Activated O estado operacional normal de um link. O tráfego flui pelo link e ele participa das decisões de roteamento. ### Soft-Drained -Um estado de manutenção onde o tráfego será desencorajado em um link específico. Utilizado para janelas de manutenção gradual. Pode transicionar para [activated](#activated) ou [hard-drained](#hard-drained). +Um estado de manutenção onde o tráfego será desencorajado em um link específico. Usado para janelas de manutenção gradual. Pode transicionar para [activated](#activated) ou [hard-drained](#hard-drained). ### Hard-Drained Um estado de manutenção onde o link é completamente removido do serviço. Nenhum tráfego flui pelo link. Deve transicionar para [soft-drained](#soft-drained) antes de retornar ao estado [activated](#activated). --- -## Organizações & Tokens +## Organizações e Tokens ### DZF (DoubleZero Foundation) -A DoubleZero Foundation é uma empresa-fundação sem membros, sem fins lucrativos, das Ilhas Cayman, formada para apoiar o desenvolvimento, descentralização, segurança e adoção da rede DoubleZero. +A DoubleZero Foundation é uma fundação sem membros, constituída como empresa sem fins lucrativos nas Ilhas Cayman, formada para apoiar o desenvolvimento, descentralização, segurança e adoção da rede DoubleZero. ### 2Z Token -O token nativo da rede DoubleZero. Utilizado para pagamento de taxas de validadores e distribuído como recompensas aos [contribuidores](#contributor). Validadores podem pagar taxas em 2Z através de um programa de swap onchain. Consulte [Trocando SOL por 2Z](Swapping-sol-to-2z.md). +O token nativo da rede DoubleZero. Usado para pagar taxas de validadores e distribuído como recompensas aos [contribuidores](#contributor). Os validadores podem pagar taxas em 2Z através de um programa de swap onchain. Consulte [Trocando SOL por 2Z](Swapping-sol-to-2z.md). ### Contributor Um provedor de infraestrutura de rede que contribui com largura de banda e hardware para a rede DoubleZero. Os contribuidores operam [DZDs](#dzd-doublezero-device), fornecem links [WAN](#wan-link) e [DZX](#dzx-link), e recebem incentivos em tokens [2Z](#2z-token) por sua contribuição. Consulte a [Documentação para Contribuidores](contribute-overview.md) para começar. @@ -104,73 +104,73 @@ Um provedor de infraestrutura de rede que contribui com largura de banda e hardw ## Conceitos de Rede ### MTU (Maximum Transmission Unit) -O maior tamanho de pacote (em bytes) que pode ser transmitido por um link de rede. Os links WAN do DoubleZero tipicamente utilizam MTU 9000 (jumbo frames) para eficiência. +O maior tamanho de pacote (em bytes) que pode ser transmitido por um link de rede. Os WAN links do DoubleZero tipicamente usam MTU 9000 (jumbo frames) para eficiência. ### VRF (Virtual Routing and Forwarding) -Uma tecnologia que permite que múltiplas tabelas de roteamento isoladas existam no mesmo roteador físico. Os contribuidores frequentemente utilizam um VRF de gerenciamento separado para isolar o tráfego de gerenciamento do switch do tráfego de produção. +Uma tecnologia que permite que múltiplas tabelas de roteamento isoladas existam no mesmo roteador físico. Os contribuidores frequentemente usam uma VRF de gerenciamento separada para isolar o tráfego de gerenciamento do switch do tráfego de produção. ### GRE (Generic Routing Encapsulation) -Um protocolo de tunelamento que encapsula pacotes de rede dentro de pacotes IP. Utilizado por conexões [IBRL](#ibrl-increase-bandwidth-reduce-latency) e [CYOA](#cyoa-choose-your-own-adventure) para criar túneis overlay entre usuários e DZDs. +Um protocolo de tunelamento que encapsula pacotes de rede dentro de pacotes IP. Usado por conexões [IBRL](#ibrl-increase-bandwidth-reduce-latency) e [CYOA](#cyoa-choose-your-own-adventure) para criar túneis overlay entre usuários e DZDs. ### BGP (Border Gateway Protocol) -O protocolo de roteamento utilizado para troca de informações de roteamento entre redes na internet. O DoubleZero utiliza BGP internamente com ASN 65342. +O protocolo de roteamento usado para trocar informações de roteamento entre redes na internet. O DoubleZero usa BGP internamente com ASN 65342. ### ASN (Autonomous System Number) -Um identificador único atribuído a uma rede para roteamento BGP. Todos os dispositivos DoubleZero utilizam **ASN 65342** para o processo BGP interno. +Um identificador único atribuído a uma rede para roteamento BGP. Todos os dispositivos DoubleZero usam **ASN 65342** para o processo BGP interno. ### Loopback Interface -Uma interface de rede virtual em um roteador/switch utilizada para fins de gerenciamento e roteamento. Os DZDs utilizam Loopback255 (VPNv4) e Loopback256 (IPv4) para roteamento interno. +Uma interface de rede virtual em um roteador/switch usada para fins de gerenciamento e roteamento. Os DZDs usam Loopback255 (VPNv4) e Loopback256 (IPv4) para roteamento interno. ### CIDR (Classless Inter-Domain Routing) -Uma notação para especificar faixas de endereços IP. O formato é `IP/prefix-length` onde o comprimento do prefixo indica o tamanho da rede (ex.: `/29` = 8 endereços, `/24` = 256 endereços). +Uma notação para especificar faixas de endereços IP. O formato é `IP/prefix-length` onde o comprimento do prefixo indica o tamanho da rede (por exemplo, `/29` = 8 endereços, `/24` = 256 endereços). ### Jitter Variação na latência dos pacotes ao longo do tempo. Baixo jitter é crítico para aplicações em tempo real. ### RTT (Round-Trip Time) -O tempo para um pacote viajar da origem ao destino e retornar. Utilizado para medir a latência de rede entre dispositivos. +O tempo para um pacote viajar da origem ao destino e retornar. Usado para medir a latência de rede entre dispositivos. ### TWAMP (Two-Way Active Measurement Protocol) -Um protocolo para medir métricas de desempenho de rede como latência e perda de pacotes. O [Telemetry Agent](#telemetry-agent) utiliza TWAMP para coletar métricas entre DZDs. +Um protocolo para medir métricas de desempenho de rede como latência e perda de pacotes. O [Telemetry Agent](#telemetry-agent) usa TWAMP para coletar métricas entre DZDs. ### IS-IS (Intermediate System to Intermediate System) -Um protocolo de roteamento de estado de link utilizado internamente pela rede DoubleZero. As métricas IS-IS são ajustadas durante operações de [drenagem de link](#soft-drained). +Um protocolo de roteamento de estado de link usado internamente pela rede DoubleZero. As métricas IS-IS são ajustadas durante operações de [drenagem de link](#soft-drained). --- ## Geolocalização -### Geolocalização -Um serviço do DoubleZero que verifica a localização física dos dispositivos utilizando medições de latência. Medições de [RTT](#rtt-round-trip-time) entre infraestrutura de localização conhecida ([DZDs](#dzd-doublezero-device)) e dispositivos-alvo fornecem prova assinada criptograficamente de que um dispositivo está dentro de uma certa distância de um ponto de referência. O registro onchain das medições está planejado para uma versão futura. Consulte [Geolocalização](geolocation.md) para documentação do usuário. +### Geolocation +Um serviço do DoubleZero que verifica a localização física dos dispositivos usando medições de latência. Medições de [RTT](#rtt-round-trip-time) entre infraestrutura de localização conhecida ([DZDs](#dzd-doublezero-device)) e dispositivos alvo fornecem prova assinada criptograficamente de que um dispositivo está dentro de uma certa distância de um ponto de referência. O registro onchain das medições está planejado para uma versão futura. Consulte [Geolocalização](geolocation.md) para documentação do usuário. ### geoProbe -Um servidor bare metal que atua como intermediário para medições de latência no sistema de [Geolocalização](#geolocalização). Os geoProbes estão localizados a ~1ms de um [DZD](#dzd-doublezero-device), recebem LocationOffsets assinados dos DZDs pai e medem [RTT](#rtt-round-trip-time) para dispositivos-alvo via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP assinado ou ICMP echo. Cada geoProbe é registrado [onchain](#onchain) e vinculado a um ou mais DZDs pai. Consulte [Implantação de Geoprobe](contribute-geolocation.md) para documentação de contribuidores. +Um servidor bare metal que atua como intermediário para medições de latência no sistema de [Geolocalização](#geolocation). Os geoProbes estão localizados a ~1ms de um [DZD](#dzd-doublezero-device), recebem LocationOffsets assinados dos DZDs pai e medem o [RTT](#rtt-round-trip-time) para dispositivos alvo via [TWAMP](#twamp-two-way-active-measurement-protocol), TWAMP assinado ou ICMP echo. Cada geoProbe é registrado [onchain](#onchain) e vinculado a um ou mais DZDs pai. Consulte [Implantação de Geoprobe](contribute-geolocation.md) para documentação de contribuidores. ### LocationOffset Uma estrutura de dados assinada contendo a localização geográfica de um [DZD](#dzd-doublezero-device) (latitude e longitude) e uma cadeia de relações de latência entre entidades (DZD↔Probe ou Probe↔Alvo). Os LocationOffsets são assinados com Ed25519 e enviados via UDP através da cadeia de medição. Offsets compostos incluem referências a medições anteriores, criando uma trilha auditável. --- -## Blockchain & Chaves +## Blockchain e Chaves ### Onchain -No contexto do DoubleZero, onchain refere-se a dados e operações registrados no ledger do DoubleZero. Diferente de redes tradicionais onde as configurações de dispositivos e links residem em sistemas de gerenciamento centralizados, o DoubleZero registra registros de dispositivos, configurações de links e submissões de telemetria onchain — tornando o estado da rede transparente e verificável por todos os participantes. +No contexto do DoubleZero, onchain refere-se a dados e operações registrados no ledger do DoubleZero. Diferentemente de redes tradicionais onde as configurações de dispositivos e links residem em sistemas de gerenciamento centralizados, o DoubleZero registra cadastros de dispositivos, configurações de links e submissões de telemetria onchain — tornando o estado da rede transparente e verificável por todos os participantes. ### Service Key -Um par de chaves criptográficas utilizado para autenticar operações da CLI. Esta é sua identidade de contribuidor para interagir com o smart contract do DoubleZero. Armazenada em `~/.config/solana/id.json`. +Um par de chaves criptográficas usado para autenticar operações do CLI. Esta é sua identidade de contribuidor para interagir com o smart contract do DoubleZero. Armazenada em `~/.config/solana/id.json`. ### Metrics Publisher Key -Um par de chaves criptográficas utilizado pelo [Telemetry Agent](#telemetry-agent) para assinar submissões de métricas na blockchain. Separada da service key para isolamento de segurança. Armazenada em `~/.config/doublezero/metrics-publisher.json`. +Um par de chaves criptográficas usado pelo [Telemetry Agent](#telemetry-agent) para assinar submissões de métricas ao blockchain. Separada da service key para isolamento de segurança. Armazenada em `~/.config/doublezero/metrics-publisher.json`. ### Rewards Manager Key -Um par de chaves criptográficas que controla para onde as recompensas de um contribuidor são pagas. Ele assina alterações na lista de carteiras destinatárias, mas nunca detém recompensas em si. Registrada contra a [Service Key](#service-key) do contribuidor pela [DZF](#dzf-doublezero-foundation). Consulte [Gerenciamento de Recompensas](contribute-rewards.md). +Um par de chaves criptográficas que controla para onde as recompensas de um contribuidor são pagas. Ela assina alterações na lista de carteiras destinatárias, mas nunca detém recompensas em si. Mantida separada da [Service Key](#service-key). Consulte [Gerenciamento de Recompensas](https://github.com/malbeclabs/contributors#rewards-management) no repositório de contribuidores. --- -## Hardware & Software +## Hardware e Software ### EOS (Extensible Operating System) O sistema operacional de rede da Arista que é executado nos switches DZD. Os contribuidores instalam o [Config Agent](#config-agent) e o [Telemetry Agent](#telemetry-agent) como extensões EOS. ### EOS Extension -Um pacote de software que pode ser instalado em switches Arista EOS. Os agentes DZ são distribuídos como arquivos `.rpm` e instalados via o comando `extension`. \ No newline at end of file +Um pacote de software que pode ser instalado nos switches Arista EOS. Os agentes DZ são distribuídos como arquivos `.rpm` e instalados via o comando `extension`. \ No newline at end of file diff --git a/docs/glossary.zh.md b/docs/glossary.zh.md index f7b493a..254c620 100644 --- a/docs/glossary.zh.md +++ b/docs/glossary.zh.md @@ -1,77 +1,77 @@ --- -description: DoubleZero 文档中使用的专有术语定义。 +description: DoubleZero 专用术语的定义，贯穿整个文档使用。 --- # 术语表 -本页面定义了文档中使用的 DoubleZero 专有术语。 +本页定义了整个文档中使用的 DoubleZero 专用术语。 --- ## 网络基础设施 -### DZD (DoubleZero Device) -终结 DoubleZero 链路并运行 DoubleZero Agent 软件的物理网络交换硬件。DZD 部署在数据中心，提供路由、数据包处理和用户连接服务。每个 DZD 需要满足特定的[硬件规格](contribute.md#dzd-network-hardware)，并同时运行 [Config Agent](#config-agent) 和 [Telemetry Agent](#telemetry-agent)。 +### DZD（DoubleZero Device） +终接 DoubleZero 链路并运行 DoubleZero Agent 软件的物理网络交换硬件。DZD 部署在数据中心，提供路由、数据包处理和用户连接服务。每个 DZD 需要满足特定的[硬件规格要求](contribute.md#dzd-network-hardware)，并同时运行 [Config Agent](#config-agent) 和 [Telemetry Agent](#telemetry-agent)。 -### DZX (DoubleZero Exchange) -网状网络中的互联点，不同[贡献者](#contributor)的链路在此处桥接在一起。DZX 位于主要大都市区域（例如纽约、伦敦、东京）中网络交汇的位置。网络贡献者必须将其链路在最近的 DZX 处交叉连接到更广泛的 DoubleZero 网状网络中。概念上类似于互联网交换点（IX）。 +### DZX（DoubleZero Exchange） +Mesh 网络中的互联点，不同[贡献者](#contributor贡献者)的链路在此桥接。DZX 位于网络交汇的主要都会区（例如 NYC、LON、TYO）。网络贡献者必须在最近的 DZX 将其链路交叉连接到更广泛的 DoubleZero mesh 中。概念上类似于互联网交换中心（IX）。 ### WAN Link -由**同一**贡献者运营的两个 [DZD](#dzd-doublezero-device) 之间的广域网链路。WAN 链路在单个贡献者的基础设施内提供骨干连接。 +由**同一**贡献者运营的两个 [DZD](#dzddoublezero-device) 之间的广域网链路。WAN Link 在单个贡献者的基础设施内提供骨干连接。 ### DZX Link -由**不同**贡献者运营的 [DZD](#dzd-doublezero-device) 之间的链路，在 [DZX](#dzx-doublezero-exchange) 处建立。DZX 链路需要双方明确接受。 +由**不同**贡献者运营的 [DZD](#dzddoublezero-device) 之间的链路，在 [DZX](#dzxdoublezero-exchange) 建立。DZX Link 需要双方明确接受。 ### DZ Prefix -以 CIDR 格式分配给 [DZD](#dzd-doublezero-device) 的 IP 地址，用于覆盖网络寻址。在[设备创建](contribute-provisioning.md#step-32-create-your-device-onchain)时通过 `--dz-prefixes` 参数指定。 +以 CIDR 格式分配给 [DZD](#dzddoublezero-device) 的 IP 地址，用于覆盖网络寻址。在[设备创建](contribute-provisioning.md#step-32-create-your-device-onchain)时通过 `--dz-prefixes` 参数指定。 --- ## 设备类型 ### Edge Device（边缘设备） -为用户提供 DoubleZero 网络连接的 [DZD](#dzd-doublezero-device)。边缘设备利用 [CYOA](#cyoa-choose-your-own-adventure) 接口终结用户（验证者、RPC 运营者）并将其连接到网络。 +为用户提供 DoubleZero 网络连接的 [DZD](#dzddoublezero-device)。边缘设备利用 [CYOA](#cyoachoose-your-own-adventure) 接口终接用户（验证者、RPC 运营商）并将其连接到网络。 -### Transit Device（中转设备） -在 DoubleZero 网络内提供骨干连接的 [DZD](#dzd-doublezero-device)。中转设备在 DZD 之间转发流量，但不直接终结用户连接。 +### Transit Device（传输设备） +在 DoubleZero 网络中提供骨干连接的 [DZD](#dzddoublezero-device)。传输设备在 DZD 之间转发流量，但不直接终接用户连接。 ### Hybrid Device（混合设备） -同时具备[边缘](#edge-device)和[中转](#transit-device)功能的 [DZD](#dzd-doublezero-device)，既提供用户连接，又提供骨干路由。 +同时具备[边缘](#edge-device边缘设备)和[传输](#transit-device传输设备)功能的 [DZD](#dzddoublezero-device)，既提供用户连接又提供骨干路由。 --- ## 连接方式 -### CYOA (Choose Your Own Adventure) -允许[贡献者](#contributor)注册连接选项的接口类型，供用户连接到 DoubleZero 网络。CYOA 接口包括 [DIA](#dia-direct-internet-access)、GRE 隧道和私有对等互联等多种方式。配置详情请参见[创建 CYOA 接口](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)。 +### CYOA（Choose Your Own Adventure） +允许[贡献者](#contributor贡献者)注册连接选项的接口类型，使用户能够连接到 DoubleZero 网络。CYOA 接口包括多种方式，如 [DIA](#diadirect-internet-access)、GRE 隧道和私有对等互联。配置详情请参阅[创建 CYOA 接口](contribute-provisioning.md#step-35-create-cyoa-interface-for-edgehybrid-devices)。 -### DIA (Direct Internet Access) -通过公共互联网提供连接的标准网络术语。在 DoubleZero 中，DIA 是一种 [CYOA](#cyoa-choose-your-own-adventure) 接口类型，用户（验证者、RPC 运营者）通过其现有的互联网连接接入 [DZD](#dzd-doublezero-device)。 +### DIA（Direct Internet Access） +通过公共互联网提供连接的标准网络术语。在 DoubleZero 中，DIA 是一种 [CYOA](#cyoachoose-your-own-adventure) 接口类型，用户（验证者、RPC 运营商）通过其现有的互联网连接接入 [DZD](#dzddoublezero-device)。 -### IBRL (Increase Bandwidth Reduce Latency) -一种连接模式，允许验证者和 RPC 节点无需重启区块链客户端即可连接到 DoubleZero。IBRL 使用现有的公共 IP 地址，并与最近的 [DZD](#dzd-doublezero-device) 建立覆盖隧道。设置说明请参见[主网 Beta 版连接](DZ%20Mainnet-beta%20Connection.md)。 +### IBRL（Increase Bandwidth Reduce Latency） +一种连接模式，允许验证者和 RPC 节点无需重启区块链客户端即可连接到 DoubleZero。IBRL 使用现有的公共 IP 地址，并与最近的 [DZD](#dzddoublezero-device) 建立覆盖隧道。设置说明请参阅 [Mainnet-Beta 连接](DZ%20Mainnet-beta%20Connection.md)。 ### Multicast（组播） -DoubleZero 支持的一对多数据包传递方式。组播模式有两种角色：**发布者**（通过网络发送数据包）和**订阅者**（从发布者接收数据包）。开发团队用于高效的数据分发。连接详情请参见[其他组播连接](Other%20Multicast%20Connection.md)。 +DoubleZero 支持的一对多数据包传输方式。组播模式有两个角色：**发布者**（publisher，通过网络发送数据包）和**订阅者**（subscriber，接收发布者的数据包）。开发团队用于高效的数据分发。连接详情请参阅[其他组播连接](Other%20Multicast%20Connection.md)。 --- ## 软件组件 ### doublezerod -运行在用户服务器（验证者、RPC 节点）上的 DoubleZero 守护进程服务。它管理与 DoubleZero 网络的连接，处理隧道建立，并维护与 [DZD](#dzd-doublezero-device) 的连接。通过 systemd 配置，并通过 [`doublezero`](#doublezero-cli) CLI 控制。 +运行在用户服务器（验证者、RPC 节点）上的 DoubleZero 守护进程服务。它管理与 DoubleZero 网络的连接，处理隧道建立，并维护与 [DZD](#dzddoublezero-device) 的连接。通过 systemd 配置，通过 [`doublezero`](#doublezero-cli) CLI 控制。 -### doublezero (CLI) -用于与 DoubleZero 网络交互的命令行界面。用于连接、管理身份、检查状态和执行管理操作。与 [`doublezerod`](#doublezerod) 守护进程通信。 +### doublezero（CLI） +与 DoubleZero 网络交互的命令行界面。用于连接、管理身份、检查状态和管理操作。与 [`doublezerod`](#doublezerod) 守护进程通信。 ### Config Agent -运行在 [DZD](#dzd-doublezero-device) 上的软件代理，负责管理设备配置。从 [Controller](#controller) 服务读取配置并将更改应用到设备。设置请参见 [Config Agent 安装](contribute-provisioning.md#step-44-install-config-agent)。 +运行在 [DZD](#dzddoublezero-device) 上的软件代理，管理设备配置。从 [Controller](#controller) 服务读取配置并将更改应用到设备。设置请参阅 [Config Agent 安装](contribute-provisioning.md#step-44-install-config-agent)。 ### Telemetry Agent -运行在 [DZD](#dzd-doublezero-device) 上的软件代理，收集性能指标（延迟、抖动、丢包率）并提交到 DoubleZero 账本。设置请参见 [Telemetry Agent 安装](contribute-provisioning.md#step-45-install-telemetry-agent)。 +运行在 [DZD](#dzddoublezero-device) 上的软件代理，收集性能指标（延迟、抖动、丢包率）并提交到 DoubleZero 账本。设置请参阅 [Telemetry Agent 安装](contribute-provisioning.md#step-45-install-telemetry-agent)。 ### Controller -为 [DZD](#dzd-doublezero-device) 代理提供配置的服务。Controller 从 DoubleZero 账本上的[链上](#onchain)状态派生设备配置。 +为 [DZD](#dzddoublezero-device) 代理提供配置的服务。Controller 从 DoubleZero 账本上的[链上](#onchain链上)状态派生设备配置。 --- @@ -81,96 +81,96 @@ DoubleZero 支持的一对多数据包传递方式。组播模式有两种角色 链路的正常运行状态。流量通过该链路传输，并参与路由决策。 ### Soft-Drained（软排空） -一种维护状态，流量将被引导远离特定链路。用于优雅的维护窗口。可以转换为[已激活](#activated)或[硬排空](#hard-drained)状态。 +一种维护状态，流量将被引导远离特定链路。用于优雅的维护窗口。可以转换为[已激活](#activated已激活)或[硬排空](#hard-drained硬排空)状态。 ### Hard-Drained（硬排空） -一种维护状态，链路完全从服务中移除。没有流量通过该链路。必须先转换为[软排空](#soft-drained)状态，然后才能恢复为[已激活](#activated)状态。 +一种维护状态，链路完全从服务中移除。没有流量通过该链路。必须先转换为[软排空](#soft-drained软排空)状态，才能恢复为[已激活](#activated已激活)状态。 --- ## 组织与代币 -### DZF (DoubleZero Foundation) -DoubleZero Foundation 是一家无会员的开曼群岛非营利基金会公司，成立旨在支持 DoubleZero 网络的开发、去中心化、安全性和推广。 +### DZF（DoubleZero Foundation） +DoubleZero Foundation 是一家无会员的开曼群岛非营利基金会公司，成立旨在支持 DoubleZero 网络的开发、去中心化、安全性和推广采用。 ### 2Z Token -DoubleZero 网络的原生代币。用于支付验证者费用，并作为奖励分发给[贡献者](#contributor)。验证者可以通过链上兑换程序以 2Z 支付费用。请参见[将 SOL 兑换为 2Z](Swapping-sol-to-2z.md)。 +DoubleZero 网络的原生代币。用于支付验证者费用并作为奖励分配给[贡献者](#contributor贡献者)。验证者可以通过链上兑换程序使用 2Z 支付费用。请参阅[将 SOL 兑换为 2Z](Swapping-sol-to-2z.md)。 ### Contributor（贡献者） -为 DoubleZero 网络贡献带宽和硬件的网络基础设施提供者。贡献者运营 [DZD](#dzd-doublezero-device)，提供 [WAN](#wan-link) 和 [DZX](#dzx-link) 链路，并因其贡献获得 [2Z](#2z-token) 代币激励。入门请参见[贡献者文档](contribute-overview.md)。 +向 DoubleZero 网络贡献带宽和硬件的网络基础设施提供商。贡献者运营 [DZD](#dzddoublezero-device)，提供 [WAN](#wan-link) 和 [DZX](#dzx-link) 链路，并因其贡献获得 [2Z](#2z-token) 代币激励。入门请参阅[贡献者文档](contribute-overview.md)。 --- ## 网络概念 -### MTU (Maximum Transmission Unit) -可以通过网络链路传输的最大数据包大小（以字节为单位）。DoubleZero WAN 链路通常使用 MTU 9000（巨型帧）以提高效率。 +### MTU（Maximum Transmission Unit，最大传输单元） +网络链路上可传输的最大数据包大小（以字节为单位）。DoubleZero WAN 链路通常使用 MTU 9000（巨型帧）以提高效率。 -### VRF (Virtual Routing and Forwarding) -一种允许多个隔离路由表共存于同一物理路由器上的技术。贡献者通常使用单独的管理 VRF 将交换机管理流量与生产流量隔离。 +### VRF（Virtual Routing and Forwarding，虚拟路由和转发） +一种允许多个隔离的路由表在同一物理路由器上共存的技术。贡献者通常使用单独的管理 VRF 来隔离交换机管理流量和生产流量。 -### GRE (Generic Routing Encapsulation) -一种将网络数据包封装在 IP 数据包内的隧道协议。[IBRL](#ibrl-increase-bandwidth-reduce-latency) 和 [CYOA](#cyoa-choose-your-own-adventure) 连接使用 GRE 在用户和 DZD 之间创建覆盖隧道。 +### GRE（Generic Routing Encapsulation，通用路由封装） +一种将网络数据包封装在 IP 数据包内的隧道协议。[IBRL](#ibrl-increase-bandwidth-reduce-latency) 和 [CYOA](#cyoachoose-your-own-adventure) 连接使用 GRE 在用户和 DZD 之间创建覆盖隧道。 -### BGP (Border Gateway Protocol) +### BGP（Border Gateway Protocol，边界网关协议） 用于在互联网上的网络之间交换路由信息的路由协议。DoubleZero 内部使用 BGP，ASN 为 65342。 -### ASN (Autonomous System Number) +### ASN（Autonomous System Number，自治系统编号） 分配给网络用于 BGP 路由的唯一标识符。所有 DoubleZero 设备的内部 BGP 进程使用 **ASN 65342**。 ### Loopback Interface（环回接口） -路由器/交换机上用于管理和路由目的的虚拟网络接口。DZD 使用 Loopback255 (VPNv4) 和 Loopback256 (IPv4) 进行内部路由。 +路由器/交换机上用于管理和路由目的的虚拟网络接口。DZD 使用 Loopback255（VPNv4）和 Loopback256（IPv4）进行内部路由。 -### CIDR (Classless Inter-Domain Routing) -用于指定 IP 地址范围的表示法。格式为 `IP/prefix-length`，其中前缀长度表示网络大小（例如，`/29` = 8 个地址，`/24` = 256 个地址）。 +### CIDR（Classless Inter-Domain Routing，无类别域间路由） +一种用于指定 IP 地址范围的表示法。格式为 `IP/prefix-length`，其中前缀长度表示网络大小（例如，`/29` = 8 个地址，`/24` = 256 个地址）。 ### Jitter（抖动） 数据包延迟随时间的变化。低抖动对实时应用至关重要。 -### RTT (Round-Trip Time) -数据包从源到目的地再返回所需的时间。用于测量设备之间的网络延迟。 +### RTT（Round-Trip Time，往返时间） +数据包从源端到目的端再返回所需的时间。用于测量设备间的网络延迟。 -### TWAMP (Two-Way Active Measurement Protocol) +### TWAMP（Two-Way Active Measurement Protocol，双向主动测量协议） 一种用于测量延迟和丢包率等网络性能指标的协议。[Telemetry Agent](#telemetry-agent) 使用 TWAMP 在 DZD 之间收集指标。 -### IS-IS (Intermediate System to Intermediate System) -DoubleZero 网络内部使用的链路状态路由协议。在[链路排空](#soft-drained)操作期间会调整 IS-IS 度量值。 +### IS-IS（Intermediate System to Intermediate System，中间系统到中间系统） +DoubleZero 网络内部使用的链路状态路由协议。在[链路排空](#soft-drained软排空)操作期间会调整 IS-IS 指标。 --- ## 地理定位 ### Geolocation（地理定位） -DoubleZero 的一项服务，通过延迟测量验证设备的物理位置。已知位置的基础设施（[DZD](#dzd-doublezero-device)）与目标设备之间的 [RTT](#rtt-round-trip-time) 测量提供经过加密签名的证明，证明设备位于参考点的一定距离内。链上记录测量数据计划在未来版本中实现。用户文档请参见[地理定位](geolocation.md)。 +DoubleZero 的一项服务，通过延迟测量验证设备的物理位置。已知位置的基础设施（[DZD](#dzddoublezero-device)）与目标设备之间的 [RTT](#rttround-trip-time往返时间) 测量提供了经过加密签名的证明，证明设备位于参考点的一定距离内。链上记录测量数据计划在未来版本中实现。用户文档请参阅[地理定位](geolocation.md)。 ### geoProbe -在[地理定位](#geolocation)系统中充当延迟测量中介的裸金属服务器。geoProbe 位于距 [DZD](#dzd-doublezero-device) 约 1ms 以内的位置，从父级 DZD 接收签名的 LocationOffset，并通过 [TWAMP](#twamp-two-way-active-measurement-protocol)、签名 TWAMP 或 ICMP echo 测量到目标设备的 [RTT](#rtt-round-trip-time)。每个 geoProbe 在[链上](#onchain)注册并关联到一个或多个父级 DZD。贡献者文档请参见 [Geoprobe 部署](contribute-geolocation.md)。 +在[地理定位](#geolocation地理定位)系统中充当延迟测量中介的裸金属服务器。geoProbe 位于距 [DZD](#dzddoublezero-device) ~1ms 以内的位置，从父 DZD 接收签名的 LocationOffset，并通过 [TWAMP](#twamptwoway-active-measurement-protocol双向主动测量协议)、签名 TWAMP 或 ICMP echo 测量到目标设备的 [RTT](#rttround-trip-time往返时间)。每个 geoProbe 都在[链上](#onchain链上)注册并关联到一个或多个父 DZD。贡献者文档请参阅 [Geoprobe 部署](contribute-geolocation.md)。 ### LocationOffset -一种签名数据结构，包含 [DZD](#dzd-doublezero-device) 的地理位置（经纬度）以及实体之间的延迟关系链（DZD↔Probe 或 Probe↔Target）。LocationOffset 使用 Ed25519 签名，并通过 UDP 在测量链中发送。复合偏移量包含对先前测量的引用，形成可审计的追踪链。 +一种签名数据结构，包含 [DZD](#dzddoublezero-device) 的地理位置（纬度和经度）以及实体之间的延迟关系链（DZD↔Probe 或 Probe↔Target）。LocationOffset 使用 Ed25519 签名，并通过 UDP 在测量链中发送。复合偏移包含对先前测量的引用，创建可审计的追踪链。 --- ## 区块链与密钥 ### Onchain（链上） -在 DoubleZero 语境中，链上指记录在 DoubleZero 账本上的数据和操作。与传统网络中设备和链路配置存储在集中管理系统中不同，DoubleZero 将设备注册、链路配置和遥测提交记录在链上——使网络状态对所有参与者透明且可验证。 +在 DoubleZero 的语境中，链上是指记录在 DoubleZero 账本上的数据和操作。与传统网络中设备和链路配置存储在集中管理系统不同，DoubleZero 将设备注册、链路配置和遥测提交记录在链上——使网络状态对所有参与者透明且可验证。 ### Service Key（服务密钥） -用于验证 CLI 操作的加密密钥对。这是您与 DoubleZero 智能合约交互时的贡献者身份。存储在 `~/.config/solana/id.json`。 +用于验证 CLI 操作的加密密钥对。这是您与 DoubleZero 智能合约交互的贡献者身份。存储在 `~/.config/solana/id.json`。 ### Metrics Publisher Key（指标发布密钥） -[Telemetry Agent](#telemetry-agent) 用于签名提交到区块链的指标数据的加密密钥对。出于安全隔离的目的，与服务密钥分开。存储在 `~/.config/doublezero/metrics-publisher.json`。 +[Telemetry Agent](#telemetry-agent) 用于签名提交到区块链的指标数据的加密密钥对。为了安全隔离，与服务密钥分开。存储在 `~/.config/doublezero/metrics-publisher.json`。 ### Rewards Manager Key（奖励管理密钥） -控制贡献者奖励支付去向的加密密钥对。它签名对接收钱包列表的更改，但自身从不持有奖励。由 [DZF](#dzf-doublezero-foundation) 针对贡献者的 [Service Key](#service-key) 进行注册。请参见[奖励管理](contribute-rewards.md)。 +控制贡献者奖励支付地址的加密密钥对。它签署对接收钱包列表的更改，但本身不持有奖励。与 [Service Key](#service-key服务密钥) 分开保管。请参阅贡献者仓库中的[奖励管理](https://github.com/malbeclabs/contributors#rewards-management)。 --- ## 硬件与软件 -### EOS (Extensible Operating System) -Arista 的网络操作系统，运行在 DZD 交换机上。贡献者将 [Config Agent](#config-agent) 和 [Telemetry Agent](#telemetry-agent) 作为 EOS 扩展进行安装。 +### EOS（Extensible Operating System） +Arista 的网络操作系统，运行在 DZD 交换机上。贡献者将 [Config Agent](#config-agent) 和 [Telemetry Agent](#telemetry-agent) 作为 EOS 扩展安装。 -### EOS Extension -可以安装在 Arista EOS 交换机上的软件包。DZ 代理以 `.rpm` 文件形式分发，通过 `extension` 命令安装。 \ No newline at end of file +### EOS Extension（EOS 扩展） +可以安装在 Arista EOS 交换机上的软件包。DZ 代理以 `.rpm` 文件分发，通过 `extension` 命令安装。 \ No newline at end of file