Skip to content

chore: sync translations with current English docs #162

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Jared-dz merged 1 commit into from
Mar 26, 2026
Merged

chore: sync translations with current English docs #162

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 56 additions & 42 deletions docs/Validator Multicast Connection.es.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,75 +3,89 @@

!!! warning "Al conectarme a DoubleZero acepto los [Términos de Servicio de DoubleZero](https://doublezero.xyz/terms-protocol)"

Si aún no está conectado a DoubleZero, complete primero la documentación de [Configuración](setup.md) y de conexión para validadores [Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md).
!!! note inline end "Empresas de trading y negocios"
Si opera una empresa de trading o un negocio que desea suscribirse al feed, se compartirán más detalles próximamente. Registre su interés para obtener más información [aquí](https://doublezero.xyz/edge-form).

Si ya es un validador conectado a DoubleZero puede continuar con esta guía.
Si aún no está conectado a DoubleZero, complete la documentación de [Configuración](https://docs.malbeclabs.com/setup/) y de conexión de validador [Mainnet-Beta](https://docs.malbeclabs.com/DZ%20Mainnet-beta%20Connection/).

#### Jito-Agave (versión 3.1.9 o superior)
Si es un validador ya conectado a DoubleZero, puede continuar con esta guía.

1. En el script de inicio de su validador, añada: `--shred-receiver-address 233.84.178.1:7733`
## 1. Configuración del Cliente

Puede enviar a Jito y al grupo `bebop` al mismo tiempo.
### Jito-Agave (v3.1.9+) y Harmonic (3.1.11+)

ejemplo:
1. En su script de inicio del validador, agregue: `--shred-receiver-address 233.84.178.1:7733`

Puede enviar a Jito y al grupo `edge-solana-shreds` al mismo tiempo.

Ejemplo:

```json
#!/bin/bash
export PATH="/home/sol/.local/share/solana/install/releases/v3.1.9-jito/bin:$PATH"
BLOCK_ENGINE_URL=https://ny.mainnet.block-engine.jito.wtf
RELAYER_URL=http://ny.mainnet.relayer.jito.wtf:8100
SHRED_RECEIVER_ADDR=<JitoBlockEngineAddress>
<...El resto de su configuración...>
<...The rest of your config...>
--shred-receiver-address 233.84.178.1:7733
```

2. Reinicie su validador.
3. Conéctese al grupo de multicast de DoubleZero `edge-solana-shreds` como publicador: `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`

3. Conéctese al grupo multicast `bebop` de DoubleZero como publicador:
`doublezero connect multicast --publish bebop`

### Frankendancer

1. En `config.toml`, agregue:

#### Frankendancer
```toml
[tiles.shred]
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
```

1. En `config.toml`, añada:
```toml
[tiles.shred]
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
```
2. Reinicie su validador.
3. Conéctese al grupo de multicast de DoubleZero `edge-solana-shreds` como publicador: `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`

## 2. Confirmar que está publicando shreds de líder

Una vez conectado, puede verificar [este panel](https://data.malbeclabs.com/dz/publisher-check) para confirmar que está publicando shreds. No verá la confirmación hasta que haya publicado shreds de líder para al menos un slot.

## 3. Recompensas para Validadores

Por cada época en que los validadores publiquen shreds de líder, serán recompensados proporcionalmente por su contribución según las suscripciones. Los detalles de este sistema serán anunciados y detallados en una fecha posterior.

## Solución de Problemas

### No se publican shreds de líder:

La causa más común de no transmitir shreds es la versión del cliente:

Debe estar ejecutando Jito-Agave 3.1.9+, JitoBam 3.1.9+, Frankendancer o Harmonic 3.1.11+. Otras versiones de cliente no funcionarán.

### Retransmisión:

1. Una causa común de retransmisión de shreds es una configuración simple. Es posible que tenga habilitado el flag para enviar shreds de retransmisión en su script de inicio; deberá deshabilitarlo.

El flag que debe eliminar en Jito-Agave es: `--shred-retransmit-receiver-address`.

1. Revise el [panel de publicadores](https://data.malbeclabs.com/dz/publisher-check) y compruebe si tiene shreds retransmitidos. En la tabla, observe la columna **No Retransmit Shreds**—una X roja significa que está retransmitiendo.

!!! note "Vista de época"
Tenga en cuenta que hay diferentes ventanas de tiempo para ver el panel de publicadores. Si ve retransmisión en la **vista de 2 épocas**, pero realizó un cambio reciente, intente cambiar a la vista de **slot reciente**.

3. Conéctese al grupo multicast `bebop` de DoubleZero como publicador:
`doublezero connect multicast --publish bebop`
![Panel de verificación de publicadores](images/publisher-check-dashboard.png)

2. Encuentre la IP de su cliente y busque su usuario en [DoubleZero Data](https://data.malbeclabs.com/dz/users).

![Usuarios de DoubleZero Data](images/doublezero-data-users.png)

!!! note inline end
Los usuarios de Frankendancer en modo driver XDP no pueden usar tcpdump. Actualmente no hay forma de confirmar que está publicando, pero pronto habrá una solución disponible.
3. Haga clic en **Multicast** para abrir su vista de multicast.

#### Confirme que está publicando
La captura de pantalla a continuación muestra: **Retransmitiendo** (indeseable) tráfico saliente constante sin patrón de slot de líder.

Durante su próximo slot de líder, use `tcpdump` para confirmar que está publicando al grupo multicast. Debería ver un heartbeat cada 10 segundos para verificar que está publicando shreds.
![Vista multicast del usuario — ejemplo de retransmisión](images/user-multicast-view-retransmit.png)

Ejecute: `sudo tcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765`
La captura de pantalla a continuación muestra: **Saludable** (publicando solo shreds de líder) tráfico saliente en picos, conocido como patrón de diente de sierra, que se alinea con sus slots de líder.

Ejemplo de salida cuando se está publicando:
![Vista multicast del usuario — ejemplo de publicador saludable](images/user-multicast-view-healthy.png)

```
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodetcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765
tcpdump: listening on doublezero1, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
21:53:11.018243 IP (tos 0x0, ttl 32, id 47109, offset 0, flags [DF], proto UDP (17), length 32)
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
21:53:21.018217 IP (tos 0x0, ttl 32, id 47558, offset 0, flags [DF], proto UDP (17), length 32)
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
21:53:31.018042 IP (tos 0x0, ttl 32, id 47919, offset 0, flags [DF], proto UDP (17), length 32)
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
21:53:32.822061 IP (tos 0x0, ttl 64, id 5721, offset 0, flags [DF], proto UDP (17), length 1231)
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0xadfc!] UDP, length 1203
21:53:32.822110 IP (tos 0x0, ttl 64, id 5722, offset 0, flags [DF], proto UDP (17), length 1231)
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0x9e62!] UDP, length 1203
5 packets captured
204 packets received by filter
0 packets dropped by kernel
```
El gráfico muestra si está enviando solo shreds de líder. Los picos de tráfico deben alinearse con cuando tiene un slot de líder. Cuando no tiene un slot de líder, no debe haber tráfico. Si está retransmitiendo, verá un flujo constante de tráfico en lugar de picos alineados con slots.
92 changes: 53 additions & 39 deletions docs/Validator Multicast Connection.fr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,17 +3,22 @@

!!! warning "En me connectant à DoubleZero, j'accepte les [Conditions d'Utilisation de DoubleZero](https://doublezero.xyz/terms-protocol)"

Si vous n'êtes pas encore connecté à DoubleZero, veuillez compléter la documentation [Configuration](setup.md) et de connexion validateur [Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md).
!!! note inline end "Sociétés de trading et entreprises"
Si vous exploitez une société de trading ou une entreprise souhaitant s'abonner au flux, plus de détails seront partagés prochainement. Enregistrez votre intérêt pour obtenir plus d'informations [ici](https://doublezero.xyz/edge-form).

Si vous n'êtes pas encore connecté à DoubleZero, veuillez d'abord compléter la documentation de [Configuration](https://docs.malbeclabs.com/setup/) et de connexion validateur [Mainnet-Beta](https://docs.malbeclabs.com/DZ%20Mainnet-beta%20Connection/).

Si vous êtes un validateur déjà connecté à DoubleZero, vous pouvez continuer ce guide.

#### Jito-Agave (version 3.1.9 ou supérieure)
## 1. Configuration du Client

### Jito-Agave (v3.1.9+) et Harmonic (3.1.11+)

1. Dans votre script de démarrage du validateur, ajoutez : `--shred-receiver-address 233.84.178.1:7733`

Vous pouvez envoyer à Jito et au groupe `bebop` en même temps.
Vous pouvez envoyer à Jito et au groupe `edge-solana-shreds` en même temps.

exemple :
Exemple :

```json
#!/bin/bash
Expand All @@ -26,52 +31,61 @@ Si vous êtes un validateur déjà connecté à DoubleZero, vous pouvez continue
```

2. Redémarrez votre validateur.
3. Connectez-vous au groupe multicast DoubleZero `edge-solana-shreds` en tant que publicateur : `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`

3. Connectez-vous au groupe multicast DoubleZero `bebop` en tant qu'éditeur :
`doublezero connect multicast --publish bebop`

### Frankendancer

1. Dans `config.toml`, ajoutez :

#### Frankendancer
```toml
[tiles.shred]
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
```

1. Dans `config.toml`, ajoutez :
```toml
[tiles.shred]
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
```
2. Redémarrez votre validateur.
3. Connectez-vous au groupe multicast DoubleZero `edge-solana-shreds` en tant que publicateur : `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`

## 2. Confirmer que vous publiez des shreds de leader

Une fois connecté, vous pouvez vérifier [ce tableau de bord](https://data.malbeclabs.com/dz/publisher-check) pour confirmer que vous publiez des shreds. Vous ne verrez pas de confirmation tant que vous n'aurez pas publié des shreds de leader pour au moins un slot.

## 3. Récompenses des Validateurs

Pour chaque époque où les validateurs publient des shreds de leader, ils seront récompensés proportionnellement pour leur contribution en fonction des abonnements. Les détails de ce système seront annoncés et détaillés ultérieurement.

## Dépannage

### Pas de publication de shreds de leader :

La cause la plus fréquente de non-transmission des shreds est la version du client :

Vous devez utiliser Jito-Agave 3.1.9+, JitoBam 3.1.9+, Frankendancer ou Harmonic 3.1.11+. Les autres versions de client ne fonctionneront pas.

### Retransmission :

1. Une cause courante de retransmission de shreds est une configuration simple. Vous avez peut-être activé le flag d'envoi de shreds de retransmission dans votre script de démarrage ; vous devrez le désactiver.

Le flag à supprimer dans Jito-Agave est : `--shred-retransmit-receiver-address`.

1. Vérifiez le [tableau de bord des publicateurs](https://data.malbeclabs.com/dz/publisher-check) et voyez si vous avez des shreds retransmis. Dans le tableau, regardez la colonne **No Retransmit Shreds**—une croix rouge signifie que vous retransmettez.

!!! note "Vue par époque"
Notez qu'il existe différentes fenêtres temporelles pour afficher le tableau de bord des publicateurs. Si vous voyez une retransmission dans la **vue 2 époques**, mais que vous avez effectué un changement récent, essayez de passer à la vue **slot récent**.

3. Connectez-vous au groupe multicast DoubleZero `bebop` en tant qu'éditeur :
`doublezero connect multicast --publish bebop`
![Tableau de bord de vérification des publicateurs](images/publisher-check-dashboard.png)

2. Trouvez l'IP de votre client et cherchez votre utilisateur dans [DoubleZero Data](https://data.malbeclabs.com/dz/users).

![Utilisateurs DoubleZero Data](images/doublezero-data-users.png)

!!! note inline end
Les utilisateurs Frankendancer en mode pilote XDP ne peuvent pas utiliser tcpdump. Il n'existe actuellement aucun moyen de confirmer que vous publiez, mais une solution sera bientôt disponible.
3. Cliquez sur **Multicast** pour ouvrir votre vue multicast.

#### Confirmer que vous publiez
La capture d'écran ci-dessous montre : **Retransmission** (indésirable) un trafic sortant constant sans motif de slot de leader.

Pendant votre prochain slot de leader, utilisez `tcpdump` pour confirmer que vous publiez vers le groupe multicast. Vous devriez voir un heartbeat toutes les 10 secondes pour vérifier que vous publiez des shreds.
![Vue multicast utilisateur — exemple de retransmission](images/user-multicast-view-retransmit.png)

Exécutez : `sudo tcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765`
La capture d'écran ci-dessous montre : **Sain** (publication uniquement de shreds de leader) un trafic sortant en pics, connu sous le nom de motif en dents de scie, qui s'aligne sur vos slots de leader.

Exemple de sortie lors de la publication :
![Vue multicast utilisateur — exemple de publicateur sain](images/user-multicast-view-healthy.png)

```
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodetcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765
tcpdump: listening on doublezero1, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
21:53:11.018243 IP (tos 0x0, ttl 32, id 47109, offset 0, flags [DF], proto UDP (17), length 32)
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
21:53:21.018217 IP (tos 0x0, ttl 32, id 47558, offset 0, flags [DF], proto UDP (17), length 32)
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
21:53:31.018042 IP (tos 0x0, ttl 32, id 47919, offset 0, flags [DF], proto UDP (17), length 32)
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
21:53:32.822061 IP (tos 0x0, ttl 64, id 5721, offset 0, flags [DF], proto UDP (17), length 1231)
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0xadfc!] UDP, length 1203
21:53:32.822110 IP (tos 0x0, ttl 64, id 5722, offset 0, flags [DF], proto UDP (17), length 1231)
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0x9e62!] UDP, length 1203
5 packets captured
204 packets received by filter
0 packets dropped by kernel
```
Le graphique indique si vous envoyez uniquement des shreds de leader. Les pics de trafic doivent s'aligner avec vos slots de leader. Lorsque vous n'avez pas de slot de leader, il ne doit y avoir aucun trafic. Si vous retransmettez, vous verrez un flux de trafic constant au lieu de pics alignés sur les slots.
Loading