Skip to content

Commit 4b7c4e3

Browse files
Jared-dzJared-dz
authored
chore: sync translations with current English docs (#162)
1 parent fbe9c7a commit 4b7c4e3

35 files changed

Lines changed: 1618 additions & 1799 deletions

‎docs/Validator Multicast Connection.es.md‎

Lines changed: 56 additions & 42 deletions
Original file line numberDiff line numberDiff line change
@@ -3,75 +3,89 @@
33

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

6-
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).
6+
!!! note inline end "Empresas de trading y negocios"
7+
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).
78

8-
Si ya es un validador conectado a DoubleZero puede continuar con esta guía.
9+
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/).
910

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

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

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

16-
ejemplo:
17+
1. En su script de inicio del validador, agregue: `--shred-receiver-address 233.84.178.1:7733`
18+
19+
Puede enviar a Jito y al grupo `edge-solana-shreds` al mismo tiempo.
20+
21+
Ejemplo:
1722

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

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

30-
3. Conéctese al grupo multicast `bebop` de DoubleZero como publicador:
31-
`doublezero connect multicast --publish bebop`
32-
36+
### Frankendancer
3337

38+
1. En `config.toml`, agregue:
3439

35-
#### Frankendancer
40+
```toml
41+
[tiles.shred]
42+
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
43+
```
3644

37-
1. En `config.toml`, añada:
38-
```toml
39-
[tiles.shred]
40-
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
41-
```
4245
2. Reinicie su validador.
46+
3. Conéctese al grupo de multicast de DoubleZero `edge-solana-shreds` como publicador: `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`
47+
48+
## 2. Confirmar que está publicando shreds de líder
49+
50+
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.
51+
52+
## 3. Recompensas para Validadores
53+
54+
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.
55+
56+
## Solución de Problemas
57+
58+
### No se publican shreds de líder:
59+
60+
La causa más común de no transmitir shreds es la versión del cliente:
61+
62+
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.
63+
64+
### Retransmisión:
65+
66+
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.
67+
68+
El flag que debe eliminar en Jito-Agave es: `--shred-retransmit-receiver-address`.
69+
70+
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.
71+
72+
!!! note "Vista de época"
73+
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**.
4374

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

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

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

49-
!!! note inline end
50-
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.
81+
3. Haga clic en **Multicast** para abrir su vista de multicast.
5182

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

54-
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.
85+
![Vista multicast del usuario — ejemplo de retransmisión](images/user-multicast-view-retransmit.png)
5586

56-
Ejecute: `sudo tcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765`
87+
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.
5788

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

60-
```
61-
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
62-
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodetcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765
63-
tcpdump: listening on doublezero1, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
64-
21:53:11.018243 IP (tos 0x0, ttl 32, id 47109, offset 0, flags [DF], proto UDP (17), length 32)
65-
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
66-
21:53:21.018217 IP (tos 0x0, ttl 32, id 47558, offset 0, flags [DF], proto UDP (17), length 32)
67-
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
68-
21:53:31.018042 IP (tos 0x0, ttl 32, id 47919, offset 0, flags [DF], proto UDP (17), length 32)
69-
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
70-
21:53:32.822061 IP (tos 0x0, ttl 64, id 5721, offset 0, flags [DF], proto UDP (17), length 1231)
71-
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0xadfc!] UDP, length 1203
72-
21:53:32.822110 IP (tos 0x0, ttl 64, id 5722, offset 0, flags [DF], proto UDP (17), length 1231)
73-
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0x9e62!] UDP, length 1203
74-
5 packets captured
75-
204 packets received by filter
76-
0 packets dropped by kernel
77-
```
91+
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.

‎docs/Validator Multicast Connection.fr.md‎

Lines changed: 53 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -3,17 +3,22 @@
33

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

6-
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).
6+
!!! note inline end "Sociétés de trading et entreprises"
7+
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).
8+
9+
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/).
710

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

10-
#### Jito-Agave (version 3.1.9 ou supérieure)
13+
## 1. Configuration du Client
14+
15+
### Jito-Agave (v3.1.9+) et Harmonic (3.1.11+)
1116

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

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

16-
exemple :
21+
Exemple :
1722

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

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

30-
3. Connectez-vous au groupe multicast DoubleZero `bebop` en tant qu'éditeur :
31-
`doublezero connect multicast --publish bebop`
32-
36+
### Frankendancer
3337

38+
1. Dans `config.toml`, ajoutez :
3439

35-
#### Frankendancer
40+
```toml
41+
[tiles.shred]
42+
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
43+
```
3644

37-
1. Dans `config.toml`, ajoutez :
38-
```toml
39-
[tiles.shred]
40-
additional_shred_destinations_leader = [ "233.84.178.1:7733", ]
41-
```
4245
2. Redémarrez votre validateur.
46+
3. Connectez-vous au groupe multicast DoubleZero `edge-solana-shreds` en tant que publicateur : `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`
47+
48+
## 2. Confirmer que vous publiez des shreds de leader
49+
50+
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.
51+
52+
## 3. Récompenses des Validateurs
53+
54+
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.
55+
56+
## Dépannage
57+
58+
### Pas de publication de shreds de leader :
59+
60+
La cause la plus fréquente de non-transmission des shreds est la version du client :
61+
62+
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.
63+
64+
### Retransmission :
65+
66+
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.
67+
68+
Le flag à supprimer dans Jito-Agave est : `--shred-retransmit-receiver-address`.
69+
70+
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.
71+
72+
!!! note "Vue par époque"
73+
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**.
4374

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

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

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

49-
!!! note inline end
50-
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.
81+
3. Cliquez sur **Multicast** pour ouvrir votre vue multicast.
5182

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

54-
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.
85+
![Vue multicast utilisateur — exemple de retransmission](images/user-multicast-view-retransmit.png)
5586

56-
Exécutez : `sudo tcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765`
87+
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.
5788

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

60-
```
61-
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
62-
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodetcpdump -vv -c5 -ni doublezero1 port 7733 or port 5765
63-
tcpdump: listening on doublezero1, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
64-
21:53:11.018243 IP (tos 0x0, ttl 32, id 47109, offset 0, flags [DF], proto UDP (17), length 32)
65-
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
66-
21:53:21.018217 IP (tos 0x0, ttl 32, id 47558, offset 0, flags [DF], proto UDP (17), length 32)
67-
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
68-
21:53:31.018042 IP (tos 0x0, ttl 32, id 47919, offset 0, flags [DF], proto UDP (17), length 32)
69-
148.51.120.2.38319 > 233.84.178.1.5765: [bad udp cksum 0xa7a9 -> 0x67ba!] UDP, length 4
70-
21:53:32.822061 IP (tos 0x0, ttl 64, id 5721, offset 0, flags [DF], proto UDP (17), length 1231)
71-
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0xadfc!] UDP, length 1203
72-
21:53:32.822110 IP (tos 0x0, ttl 64, id 5722, offset 0, flags [DF], proto UDP (17), length 1231)
73-
148.51.120.2.57512 > 233.84.178.1.7733: [bad udp cksum 0xac58 -> 0x9e62!] UDP, length 1203
74-
5 packets captured
75-
204 packets received by filter
76-
0 packets dropped by kernel
77-
```
91+
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.

0 commit comments

Comments
 (0)