mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-06 17:27:57 +00:00
Added /networks-and-servers translations
This commit is contained in:
Ekiserrepé
88
@i18n/es-ES/docs/concepts/networks-and-servers/amendments.md
Normal file
88
@i18n/es-ES/docs/concepts/networks-and-servers/amendments.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
html: amendments.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Las enmiendas representan nuevas funcionalidades u otros cambios para el procesamiento de transacciones. Los validadores se coordinan a través del consenso para aplicar estas mejoras al XRP Ledger de manera ordenada.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Enmiendas
|
||||
|
||||
Las enmiendas representan nuevas funcionalidades u otros cambios en el procesamiento de transacciones.
|
||||
|
||||
El sistema de enmiendas utiliza el proceso de consenso para aprobar cualquier cambio que afecte el procesamiento de transacciones en el XRP Ledger. Los cambios en el proceso de transacción completamente funcionales se introducen como enmiendas; luego, los validadores votan sobre estos cambios. Si una enmienda recibe más del 80% de apoyo durante dos semanas, la enmienda se aprueba y el cambio se aplica permanentemente a todas las versiones de ledgers subsiguientes. Deshabilitar una enmienda aprobada requiere una nueva enmienda para hacerlo.
|
||||
|
||||
**Nota:** Las correcciones de errores que cambian los procesos de transacción también requieren enmiendas.
|
||||
|
||||
<!-- TODO: Move this to an amendment tutorial.
|
||||
Every amendment has a unique identifying hex value and a short name. The short name is for readability only; servers can use different names to describe the same amendement ID, and the names aren't guaranteed to be unique. The amendment ID should be the SHA-512Half hash of the amendment's short name.
|
||||
-->
|
||||
|
||||
## Proceso de enmienda
|
||||
|
||||
El apartado [Código de contribución al XRP Ledger](/resources/contribute-code/index.md) describe el flujo de trabajo para desarrollar una enmienda desde una idea hasta su activación en el XRP Ledger.
|
||||
|
||||
Después de que el código para una enmienda se incluye en una versión de software o software release, el proceso para habilitarlo ocurre dentro de la red del XRP Ledger, que verifica el estado de las enmiendas en cada _flag_ ledger (generalmente cada 15 minutos).
|
||||
|
||||
Cada 256º ledger se llama **flag** ledger. El flag ledger no tiene contenidos especiales, pero el proceso de enmienda ocurre alrededor suyo.
|
||||
|
||||
1. **Flag Ledger -1:** Cuando los validadores `rippled` envían mensajes de validación, también envían sus votos sobre enmiendas.
|
||||
2. **Flag Ledger:** Los servidores interpretan los votos de los validadores confiables.
|
||||
3. **Flag Ledger +1:** Los servidores insertan la pseudo transacción `EnableAmendment` y marcan dependiendo de lo que piensan que ha pasado:
|
||||
* El flag (o marca) `tfGotMajority` significa que la enmienda tiene más del 80% del apoyo.
|
||||
* El flag (o marca) `tfLostMajority` significa que el apoyo de la enmienda ha descendido al 80% o menos.
|
||||
* Que no haya flag (o marca) significa que la enmienda está activada.
|
||||
|
||||
**Nota:** Es posible para una enmienda perder el 80% del apoyo en el mismo ledger en el que alcanza el periodo de dos semanas para ser activada. En esos casos, una pseudo-transaccion `EnableAmendment` es añadida en ambos escenarios, pero la enmienda es activada finalmente.
|
||||
|
||||
4. **Flag Ledger +2:** Enmiendas activadas aplican a transacciones en este ledger en adelante.
|
||||
|
||||
|
||||
## Votación de enmienda
|
||||
|
||||
Cada versión de `rippled` es compilada con una lista de [enmiendas conocidas](/resources/known-amendments.md) y el código para implementar esas enmiendas. Los operadores de los validadores `rippled` configuran sus servidores para votar en cada enmienda y cambiarlo en cada momento. Si un operador no elige un voto, el servidor por defecto tiene un voto definido en el códido fuente.
|
||||
|
||||
**Nota:** El voto por defecto cambia entre las publicaciones del software. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Actualizado en: rippled 1.8.1{% /badge %}
|
||||
|
||||
Las enmiendas deben mantener dos semanas el apoyo de más del 80% de los validadores confiables para activarse. Si el apoyo baja por debajo del 80%, la enmienda es temporalmente rechazada , y el periodo de dos semanas se reinicia. Las enmiendas pueden ganar y perder una mayoría cualquier cantidad de veces antes de que se habiliten permanentemente.
|
||||
|
||||
Las enmiendas que hayan tenido su código fuente removido sin haberse activado on consideradas **vetadas** por la red.
|
||||
|
||||
|
||||
## Servidores bloqueados por enmienda
|
||||
<a id="amendment-blocked"></a>
|
||||
|
||||
El bloqueo por enmienda es una característica de seguridad para proteger la precisión de los datos del XRP Ledger. Cuando una enmienda se activa, los servidores ejecutando versiones anteriores de `rippled` sin el código fuente de la enmienda ya no consiguen entender las reglas de la red. En vez de adivinar y malinterpretar los datos del ledger, estos servidores se convierten en servidores **bloqueados por enmienda** y no pueden:
|
||||
|
||||
* Determinar la validez de un ledger.
|
||||
* Enviar o procesar transacciones.
|
||||
* Participar en el proceso de consenso.
|
||||
* Votar sobre futuras enmiendas.
|
||||
|
||||
La configuración de votación de un servidor `rippled` no tiene impacto en convertirse en un servidor bloqueado por enmienda. Un servidor `rippled` siempre sigue las enmiendas activadas por el resto de la red, por lo que los bloqueos solo se basan en tener el código para entender los cambios de reglas. Esto significa que tu también te puedes convertir en alguien bloqueado por enmienda si conectas tu servidor a una red paralela con enmiendas activadas. Por ejemplo, La Devnet de XRP normalmente tiene enmiendas experimentales activadas. Si estás utilizando la última publicación o release en producción, tu servidor no tendrá ese código de esas enmiendas experimentales.
|
||||
|
||||
Puedes debloquear servidores bloqueados por enmienda actualizando a la última versión de `rippled`.
|
||||
|
||||
### Servidores Clio bloqueados por enmienda
|
||||
|
||||
Los servidores Clio pueden bloquearse por enmienda si se encuentran un tipo de campo desconocido mientras cargan los datos del ledger. Esto ocurre si el campo es más nuevo que la dependencia de `libxrpl` usada cuando se construye Clio. Para desbloquear tu servidor Clio, actualiza a la última release de Clio que se publicó con un `libxrpl` compatible.
|
||||
|
||||
## Retiro de enmiendas
|
||||
|
||||
Cuando las enmiendas son activadas, el código fuente de comportamientos previos a la enmienda permanece en `rippled`. Mientras hay casos de uso para mantener el código antiguo, como la reconstrucción de resultados de los ledgers para verificación, el seguimiento de enmiendas y código heredado agrega complejidad con el tiempo.
|
||||
|
||||
El [Estándar 11d de XRP Ledger](https://github.com/XRPLF/XRPL-Standards/discussions/19) define un proceso para retirar enmiendas antiguas y código asociado previo a la enmienda. Después de que una enmienda haya sido activada en Mainnet por dos años, puede ser retirado. Retirar una enmienda la convierte en parte del protocolo central incondicionalmente; ya no se sigue ni se trata como una enmienda, y todo el código anterior a la enmienda es eliminado.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- **Tutoriales:**
|
||||
- [Ejecutar rippled como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
|
||||
- [Configurar votación de enmiendas](../../infrastructure/configuration/configure-amendment-voting.md)
|
||||
- [Contribuir al código del XRP Ledger](/resources/contribute-code/index.md)
|
||||
- **Referencias:**
|
||||
- [Enmiendas conocidas](/resources/known-amendments.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
29
@i18n/es-ES/docs/concepts/networks-and-servers/clustering.md
Normal file
29
@i18n/es-ES/docs/concepts/networks-and-servers/clustering.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
html: clustering.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Ejecuta servidores rippled en un cluster para compartir la carga criptográfica entre ellos.
|
||||
labels:
|
||||
- Servidor principal
|
||||
---
|
||||
# Clustering
|
||||
|
||||
Si estás ejecutando varios servidores `rippled` en un único datacenter, puedes configurar esos servidores dentro de un cluster para maximizar la eficiencia. Ejecutar tus servidores `rippled` en un cluster proporciona los siguientes beneficios:
|
||||
|
||||
- Los servidores `rippled` clusterizados comparten el trabajo critográfico. Si un servidor ha verificado la autenticidad del mensaje, los otros servidores en el cluster confian en él y no lo vuelven a verificar.
|
||||
- Los servidores clusterizados comparten información sobre pares y clientes API que están comportandose mal o abusando de la red. Esto dificulta atacar todos los servidores del cluster a la vez.
|
||||
- Los servidores clusterizados siempre propagan las transacciones a través del cluster, incluso si la transacción no cumple con el coste de transacción actual basada en la carga en alguno de ellos.
|
||||
|
||||
Si estás ejecutando un validador como un [par privado](peer-protocol.md#pares-privados), Ripple recomienda utilizar un cluster de servidores `rippled` como servidores proxy.
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Tutoriales:**
|
||||
- [Cluster de servidores `rippled`](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
|
||||
- [Ejecutar rippled como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
|
||||
- **Referencias:**
|
||||
- [método peers][]
|
||||
- [método connect][]
|
||||
- [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
41
@i18n/es-ES/docs/concepts/networks-and-servers/index.md
Normal file
41
@i18n/es-ES/docs/concepts/networks-and-servers/index.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
html: networks-and-servers.html
|
||||
parent: concepts.html
|
||||
seo:
|
||||
description: rippled es el servidor peer-to-peer principal que maneja el XRP Ledger.
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# Redes y servidores
|
||||
|
||||
Hay dos tipos principales de software de servidores que alimentan el XRP Ledger:
|
||||
|
||||
- El servidor principal, `rippled`, ejecuta la red peer-to-peer la cual procesa transacciones y alcanza un consenso en sus resultados.
|
||||
- El servidor API, [Clio](the-clio-server.md), proporciona potentes interfaces para obtener o consultar datos desde el ledger.
|
||||
|
||||
Cualquiera puede ejecutar instancias de uno o ambos de estos tipos de servidores basado en sus necesidades.
|
||||
|
||||
## Razones por las que ejecutar tu propio servidor
|
||||
|
||||
Para casos de uso más livianos y servidores individuales, puedes depender de [servidores públicos][]. Sin embargo, cuanto más serio sea tu uso del XRP Ledger, más importante será tener tu propia infraestructura.
|
||||
|
||||
Hay multitud de razones por las que quieres ejecutar tus propios servidores, pero la mayoría de ellas se pueden resumir en: puedes confiar en tu propio servidor, tienes control sobre la carga de trabajo, y no estás a merced de otros que decidan cuando y cómo puedes acceder. Por supuesto, debes tener tener unas buenas prácticas respecto a la seguridad de la red para proteger tu servidor de hackers maliciosos.
|
||||
|
||||
Necesitas confiar en el servidor que utilizas. Si te conectas a un servidor malicioso, hay muchas maneras en las que se pueda aprovechar de ti o hacerte perder dinero. Por ejemplo:
|
||||
|
||||
* Un servidor malicioso podría informar que has sido pagado cuando no se ha hecho el pago.
|
||||
* Podría selectivamente mostrar u ocultar los caminos (o paths) de pago y las foertas de intercambio de divisas para garantizar su propio beneficio mientras no te ofrece la mejor oferta.
|
||||
* Si le enviaste la clave secreta de tu dirección, esto podría generar transacciones arbitrarias en tu nombre e incluso transferir o destruir todo el dinero que la dirección posee.
|
||||
|
||||
Adicionalmente, ejecutar tu propio servidor te da [acceso de administrador](../../tutorials/http-websocket-apis/build-apps/get-started.md#admin-access), lo que te permite ejecutar comandos exclusivos de administrador y de carga intensa. Si utilizas un servidor compartido, debes preocuparte por los otros usuarios del mismo servidor compitiendo contra ti por el poder de computación del servidor. Muchos de los comandos en el API WebSocket puede poner mucha presión sobre el servidor, por lo que el servidor tiene la opción de reducir sus respuestas cuando lo necesite. Si compartes un servidor con otros, puede que no siempre consigas los mejores resultados posibles.
|
||||
|
||||
Finalmente, si ejecutas un servidor de validación, puedes utilizar un servidor común como proxy a la red pública mientras mantienes tu servidor de vaalidación en una red privada la cual es solo accesible desde el mundo exterior desde tu servidor común. Esto hace más difícil comprometer la integridad de tu servidor de validación.
|
||||
|
||||
## Características y temas del servidor
|
||||
|
||||
<!-- provided by the auto-generated table of children -->
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
html: ledger-history.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Los servidores rippled almacenan una cantidad variable de transacciones e historial del estado localmente.
|
||||
labels:
|
||||
- Retención de datos
|
||||
- Blockchain
|
||||
- Servidor principal
|
||||
---
|
||||
# Histórico del ledger
|
||||
|
||||
El [proceso de consenso](../consensus-protocol/index.md) crea una cadena de [versiones de ledgers validados](../ledgers/index.md), cada uno derivado del anterior aplicando un conjunto de [transacciones](../transactions/index.md). Cada [servidor `rippled`](index.md) almacena versiones de ledgers y el historial de transacciones locálmente. La cantidad de histórico de transacciones que un servidor almacena depende de cuanto tiempo ese servidor ha estado online y cuanto histórico está configurado para recuperar y mantener.
|
||||
|
||||
Los servidores en la red peer-to-peer XRP Ledger comparten transacciones y otros datos entre sí como parte del proceso de consenso. Cada servidor construye de forma independiente una nueva versión del ledger y compara los resultados con sus validadores de confianza para asegurar la consistencia. (Si un consenso de validadores de confianza no está de acuerdo con los resultados de un servidor, ese servidor recupera los datos necesarios de sus pares para lograr consistencia.) Los servidores pueden descargar datos más antiguos de sus pares para completar huecos en su historial disponible. La estructura del ledger utiliza [hashes](../../references/protocol/data-types/basic-data-types.md#hashes) criptográficos de los datos para que cualquier servidor pueda verificar la integridad y consistencia de los datos.
|
||||
|
||||
## Bases de datos
|
||||
|
||||
Los servidores mantienen datos del estado del ledger y transacciones en un almacén de clave-valor llamada almacén del ledger o _ledger store_. Además, `rippled` mantiene algunos archivos de base de datos SQLite para un acceso más flexible a cosas como el historial de transacciones y para rastrear ciertos cambios de configuración.
|
||||
|
||||
Normalmente, es seguro eliminar todos los archivos de base de datos de un servidor `rippled` cuando ese servidor no está en funcionamiento. (Es posible que quieras hacer esto, por ejemplo, si cambias la configuración de almacenamiento del servidor o si estás cambiando de una red de prueba a la red de producción).
|
||||
|
||||
## Historial disponible
|
||||
|
||||
Por diseño, todos los datos y transacciones en el XRP Ledger son públicos y cualquiera puede buscar o consultar cualquier cosa. Sin embargo, tu servidor solo puede buscar datos que tenga disponibles localmente. Si intentas buscar una versión del ledger o una transacción que tu servidor no tenga disponible, tu servidor responderá que no puede encontrar esos datos. Otros servidores que tengan el historial necesario pueden responder con éxito a la misma consulta. Si tienes un negocio que utiliza datos del XRP Ledger, debes tener cuidado de cuánto historial tiene disponible tu servidor.
|
||||
|
||||
El [método server_info][] reporta cuántas versiones del ledger tiene disponibles en el campo `complete_ledgers`.
|
||||
|
||||
## Recuperar el histórico
|
||||
|
||||
Cuando un servidor del XRP Ledger se inicia, su primera prioridad es obtener una copia completa del último ledger validado. A partir de ahí, se mantiene al día con los avances en el progreso del ledger. El servidor completa cualquier agujero en su historial del ledger que ocurra después de sincronizar y puede rellenar el historial desde antes de que se sincronizara. (Los huecos en el historial del ledger pueden ocurrir si un servidor temporalmente se vuelve demasiado ocupado para mantenerse al día con la red, pierde su conexión de red u experimenta otros problemas temporales).Cuando descarga el historial del ledger, el servidor solicita los datos faltantes a sus [servidores pares](peer-protocol.md), y verifica la integridad de los datos utilizando [hashes][Hash] criptográficos.
|
||||
|
||||
Rellenar el histórico es uno de las prioridades más bajas del servidor, por lo que puede llevar mucho tiempo completar el historíal faltante, especialmente si el servidor está ocupado o si las especificaciones del hardware y la red no son lo suficientemente buenas. Para recomendaciones en especificaciones de hardware, ver [Planificación de capacidad](../../infrastructure/installation/capacity-planning.md). Completar el histórico también requiere que al menos uno de los pares directos del servidor tenga el histórico en cuestión. Para más información de cómo administrar las conexiones peer-to-peer de tu servidor, consulta [Configurar Peering](../../infrastructure/configuration/peering/index.md).
|
||||
|
||||
El XRP Ledger identifica datos (en varios niveles diferentes) mediante un hash único de sus contenidos. Los datos de estado del XRP Ledger contienen un resumen breve del histórico del ledger, en forma de [tipos de objeto LedgerHashes](../../references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md). Los serivodres usan los objetos LedgerHashes para conocer qué versiones del ledger hay que buscar, y confirmar que los datos del ledger que recibe son correctos y completos.
|
||||
|
||||
|
||||
<a id="with-advisory-deletion"></a><!-- old anchor to this area -->
|
||||
### Rellenar
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}Actualizado en: rippled 1.6.0{% /badge %}
|
||||
|
||||
La cantidad de histórico que un servidor intenta descargar depende de su configuración. El servidor automáticamente intenta rellenar los huecos descargando el histórico hasta **el ledger más antiguo que está actualmente disponible**. Pues utilizar el campo `[ledger_history]` para hacer al servidor rellenar el histórico más allá de ese punto. Sin embargo, el servidor nunca descarga ledgers que estuviesen programados para su [eliminación](../../infrastructure/configuration/data-retention/online-deletion.md).
|
||||
|
||||
El campo `[ledger_history]` define el número mínimo de ledgers que se acumulan antes del ledger actual validado. Utiliza el valor especial `full` para descargar el [histórico completo](#full-history) de la red. Si especificas un número de ledgers, debe ser igual o mayor que el campo `online_deletion`; no puedes utilizar `[ledger_history]` para hacer al servidor descargar _menos_ histórico. Para reducir la cantidad de histórico que un servidor almacena, cambia el ajuste [online deletion](../../infrastructure/configuration/data-retention/online-deletion.md). <!-- STYLE_OVERRIDE: a number of -->
|
||||
|
||||
|
||||
|
||||
## Histórico completo
|
||||
|
||||
Algunos servidores en la red XRP Ledger están configurados como servidores "full-history". Estos servidores, los cuales requieren sifnificativamente más espacio de disco que otros servidores de seguimiento, almacenan todo el histórico disponible XRP Ledger y **no usan la opción online deletion**.
|
||||
|
||||
La XRP Ledger Foundation proporciona acceso a un cojunto de servidores full history operados por miembros de la comunidad (ver [xrplcluster.com](https://xrplcluster.com) para más detalles).
|
||||
Ripple también proporciona un conjunto de servidores full-history públicos como un servicio público en `s2.ripple.com`. <!-- SPELLING_IGNORE: xrplcluster -->
|
||||
|
||||
Los proveedores de servidores Full History se reservan el derecho de bloquear acceso a aquellos que abusen de los rescursos, o generen una carga desproporcionada a los sistemas.
|
||||
|
||||
**Consejo:** A diferencia de algunas redes de criptomonedas, los servidores en el XRP Ledger no necesitan un full history para conocer el estado actual y mantenerse a día con las transacciones actuales.
|
||||
|
||||
Para instrucciones de cómo configurar un servidor full history, consultar [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
|
||||
|
||||
## Fragmentación del historial
|
||||
|
||||
Una alternativa para almacenar todo el histórico completo del XRP Ledger en una única máquina cara es configurar muchos servidores para que cada uno almacene una parte del histórico completo del ledger. La función [Fragmentación del histórico](../../infrastructure/configuration/data-retention/history-sharding.md) hace esto posible, almacenando rangos del histórico del ledger en áreas de almacenamiento separadas llamadas almacenes de fragmentación o _shard store_. Cuando un servidor par solicita datos específicos (como se describe en [fetching history](#recuperar-el-histórico) arriba), un servidor puede responder usando datos de su ledger store o shard store.
|
||||
|
||||
Online deletion **no** borra desde un shard store. Sin embargo, si configuras online deletion para mantener al menos 32768 versiones de ledger en el ledger store de tu servidor, tu servidor puede copiar shards completos desde el ledger store al shard store antes de borrarlos automáticamente del ledger store.
|
||||
|
||||
Para más información, ver [Configurar History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md).
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Ledgers](../ledgers/index.md)
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- **Tutoriales:**
|
||||
- [Configurar `rippled`](../../infrastructure/configuration/index.md)
|
||||
- [Configurar Online Deletion](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
|
||||
- [Configurar Advisory Deletion](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
|
||||
- [Configurar History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md)
|
||||
- [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md)
|
||||
- **Referencias:**
|
||||
- [método ledger][]
|
||||
- [método server_info][]
|
||||
- [método ledger_request][]
|
||||
- [método can_delete][]
|
||||
- [método ledger_cleaner][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
html: parallel-networks.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Entender cómo las redes de prueba (test) y cadenas ledger alternativas se relacionan con el XRP Ledger en producción.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Redes paralelas
|
||||
|
||||
Existe una red peer-to-peer en producción del XRP Ledger, y todos los negocios que tienen lugar en el XRP Ledger ocurren dentro de la red de producción: la Mainnet.
|
||||
|
||||
Para ayudar a miembros de la comunidad del XRP Ledger a interactuar con la tecnología sin afectar nada a la Mainnet, hay redes alternativas, o altnets. Aquí hay un desglose de algunas altnets públicas:
|
||||
|
||||
| Red | Cadencia de actualización | Descripción |
|
||||
|:--------|:----------------|:-------------------------------------------------|
|
||||
| Mainnet | Lanzamientos estables | _El_ [XRP Ledger](/about/), un libro contable criptográfico descentralizado impulsado por una red de servidores peer-to-peer y el hogar de [XRP](../../introduction/what-is-xrp.md). |
|
||||
| Testnet | Lanzamientos estables | Una red de "universo alternativo" que actua como un campo de pruebas para el software construido en el XRP Ledger, sin impactar a los usuarios del XRP Ledger de producción y sin arriesgar dinero real. El [estado de enmienda](/resources/known-amendments.md) de Testnet está destinado a reflejar de cerca el de la Mainnet, aunque pueden ocurrir ligeras variaciones en el tiempo debido a la naturaleza impredecible de los sistemas descentralizados. |
|
||||
| Devnet | Lanzamientos Beta | Una vista previa de las próximas atracciones, donde cambios inestables en el software principal de XRP Ledger se pueden probar. Los desarrolladores pueden utilizar esta altnet para interactuar y aprender sobre funcionalidades nuevas planficiadas para el XRP Ledger y enmiendas que no están habilitadas en la Mainnet. |
|
||||
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Servidor Hooks](https://github.com/XRPL-Labs/xrpld-hooks) | Una vista previa de la funcionalidad de smart contract en la cadena utilizando [hooks](https://xrpl-hooks.readme.io/). |
|
||||
| Sidechain-Devnet | Lanzamientos Beta | Una sidechain para probar funcionalidades en puentes cross-chain. Devnet se trata como la cadena de bloqueo y esta sidechain es la cadena de emisión.<br>Soporte a la librería:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**Nota**: También puedes usar la herramienta de línea de comandos [`xbridge-cli`](https://github.com/XRPLF/xbridge-cli) para configurar un puente entre cadenas en tu máquina local. |
|
||||
|
||||
Cada altnet tiene su propia distribución separada de XRP de prueba, que se [regala gratis](/resources/dev-tools/xrp-faucets) a partes interesadas en experimentar con el XRP Ledger y desarrollar aplicaciones e integraciones. El XRP test no tiene valor en el mundo real y se pierde cuando la red se reinicia.
|
||||
|
||||
**Atención:** A diferencia de la Mainnet del XRP Ledger, las redes de prueba suelen ser _centralizadas_ y no hay garantías sobre la estabilidad y disponibilidad de estas redes. Han sido y siguen siendo utilizadas para probar diversas propiedades de la configuración del servidor, la topología de la red y el rendimiento de la red.
|
||||
|
||||
|
||||
## Redes paralelas y consenso
|
||||
|
||||
El factor principal en determinar qué red sigue un servidor es su UNL configurado-la lista de validadores en los que confía para no colisionar. Cada servidor utiliza su UNL configurada para saber qué ledger aceptar como la verdad. Cuando diferentes grupos de consenso de instancias de `rippled` solo confían en otros miembros del mismo grupo, cada grupo continúa como una red paralela. Incluso si equipos maliciosos o malintencionados se conectan a ambas redes, el proceso de consenso evita la confusión siempre y cuando los miembros de cada red no estén configurados para confiar en miembros de otra red en exceso de su configuración de cuórum.
|
||||
|
||||
Ripple ejecuta los servidores principales en la Testnet y Devnet; también puedes [conectar tu propio servidor `rippled` para estas redes](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md). La Testnet y Devnet no utilizan conjuntos de validadores diversos y resistentes a la censura. Esto hace posible que Ripple reinicie la Testnet o Devnet en cualquier momento.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Herramientas:**
|
||||
- [XRP Testnet Faucet](/resources/dev-tools/xrp-faucets)
|
||||
- **Conceptos:**
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- [Enmiendas](amendments.md)
|
||||
- **Tutoriales:**
|
||||
- [Conectar tu `rippled` en laTestnet XRP](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
|
||||
- [Usar rippled en modo Stand-Alone](../../infrastructure/testing-and-auditing/index.md)
|
||||
- **Referencias:**
|
||||
- [método server_info][]
|
||||
- [método consensus_info][]
|
||||
- [método validator_list_sites][]
|
||||
- [método validators][]
|
||||
- [Opciones modo Daemon](../../infrastructure/commandline-usage.md#daemon-mode-options)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
174
@i18n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
Normal file
174
@i18n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
Normal file
@@ -0,0 +1,174 @@
|
||||
---
|
||||
html: peer-protocol.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: El protocolo de pares especifica el lenguaje en el que los servidores rippled hablan entre sí.
|
||||
labels:
|
||||
- Servidor principal
|
||||
- Blockchain
|
||||
---
|
||||
# Protocolo de pares
|
||||
|
||||
Los servidores en el XRP Ledger se comunican entre sí utilizando el protocolo de pares del XRP Ledger.
|
||||
|
||||
El protocolo de pares es el modo principal de comunicación entre servidores en el XRP Ledger. Toda la información sobre el comportamiento, progreso, y conectividad en el XRP Ledger pasa a través del protocolo de pares. Ejemplos de comunicación peer-to-peer incluyen todos los siguientes:
|
||||
|
||||
- Solicitar una conexión a otros servidores en la red peer-to-peer, o anunciar que hay huecos de conexión disponibles.
|
||||
- Compartir transacciones candidatas con el resto de la red.
|
||||
- Solicitar datos de ledger de ledgers históricos, o proporcionar esos datos.
|
||||
- Proponer una conjunto de transacciones para el consenso, o compartir el resultado calculado de aplicar el conjunto de transacciones de consenso.
|
||||
|
||||
Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando HTTPS y solicita una [actualización HTTP](https://tools.ietf.org/html/rfc7230#section-6.7) para cambiar al protocolo `XRPL/2.0` (anteriormente `RTXP/1.2`). (Para más información, consultar el artículo [Red de superposición](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) en el [repositorio `rippled`](https://github.com/ripple/rippled).)
|
||||
|
||||
## Descubrimiento de pares
|
||||
|
||||
El XRP Ledger utiliza el protocolo del "chismorreo" para ayudar a servidores a encontrar otros servidores para conectarse en la red XRP Ledger. Cuando un servidor se inicia, se reconecta a cualquier otro par al que se haya conectado anteriormente. Como alternativa, utiliza los [hubs públicos hardcodeados](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). Después de que un servidor se conecte correctamente a un par, le pregunta a ese par por información de contacto (generalmente, dirección IP y puerto) de otros servidores XRP Ledger que también pueden estar buscando pares. El servidor puede conectarse entonces a esos servidores, y preguntarles por información de contacto de todavía más servidores a los que conectarse. A través de este proceso, el servior hace suficientes conexiones de pares para que pueda permanecer contectado con el resto de la red incluso si pierde la conexión con cualquier par en particular.
|
||||
|
||||
Normalmente, un servidor necesita conectarse a un hub público solo una vez, durante un corto período de tiempo, para encontrar otros pares. Después de hacerlo, el servidor puede o no permanecer conectado al hub, dependiendo de la estabilidad de su conexión de red, de lo ocupado que esté el hub y de cuántos otros pares de alta calidad encuentre el servidor. El servidor guarda las direcciones de estos otros pares para poder intentar reconectarse directamente a esos pares más tarde, después de una interrupción en la red o un reinicio.
|
||||
|
||||
El [método peers][] muestra una lista de pares a los que tu servidor está actualmente conectado.
|
||||
|
||||
Para ciertos servidores de alto valor (tan importantes como [validadores](rippled-server-modes.md#modos-de-servidor-rippled)) puedes preferir no conectarte a pares no confiables a través del proceso de descubrimiento de pares. En este caso, puedes configurar tu servidor para usar solo [pares privados](#pares-privados).
|
||||
|
||||
|
||||
## Puerto del protocolo de pares
|
||||
|
||||
Para participar en el XRP Ledger, los servidores `rippled` conectan con pares arbitrarios utilizando el protocolo de pares. (Todos los pares son como no confiables, a no ser que sean de tipo [clusterizado](clustering.md) con el servidor actual.)
|
||||
|
||||
Idealmente, el servidor debería poder enviar _y_ recibir conexiones en el puerto de pares. Debes [redireccionar el puerto utilizado por el protocolo de pares a través de tu firewall](../../infrastructure/configuration/peering/forward-ports-for-peering.md) para el servidor `rippled`.
|
||||
|
||||
IANA [ha asignado el puerto **2459**](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2459) para el protocolo de pares del XRP Ledger, pero para la compatibilidad con sistemas antiguos, el [fichero de configuración por defecto de `rippled`](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg) escucha las conexiones entrantes de pares con el **port 51235** en todas las interfaces de la red. Si ejecutas un servidor, puedes configurar qué puerto(s) escucha tu servidor utilizando el fichero `rippled.cfg`.
|
||||
|
||||
Ejemplo:
|
||||
|
||||
```
|
||||
[port_peer]
|
||||
port = 2459
|
||||
ip = 0.0.0.0
|
||||
protocol = peer
|
||||
```
|
||||
|
||||
El puerto del protocolo de pares también sirve para [métodos especiales del puerto de pares](../../references/http-websocket-apis/peer-port-methods/index.md).
|
||||
|
||||
## Par de claves de nodo
|
||||
|
||||
Cuando un servidor se inicia por primera vez, genera un _par de claves de nodo_ para usarlo para identificarse en las comunicaciones del protocolo de pares. El servidor utiliza su clave para firmar todas sus comunicaciones del protocolo de pares. Esto hace posible identificar y verificar de manera confiable la integridad de los mensajes de otro servidor en la red peer-to-peer incluso si los mensajes de ese servidor están siendo transmitidos por pares no confiables.
|
||||
|
||||
El par de claves de nodo se guarda en la base de datos y se reutiliza cuando el servidor se reinicia. Si eliminas las bases de datos del servidor, crea un nuevo par de claves de nodo, lo que efectivamente le hace iniciar con una identidad diferente. Para reutilizar el mismo par de claves incluso si las bases de datos se eliminan, puedes configurar el servidor en el apartado `[node_seed]`. Para generar un valor adecuado para usar en el apartado `[node_seed]`, utiliza el [método validation_create][].
|
||||
|
||||
El par de claves de nodo también identifican otros servidores para propositos de [clustering](clustering.md) o [reservar huecos de pares](#pares-fijos-y-reservas-de-pares). Si tienes un cluster de servidores, debes configurar cada servidor en el cluster con un valor único en el apartado `[node_seed]`. Para más información de cómo configurar un cluster, ver [Servidores `rippled` clusterizados](../../infrastructure/configuration/peering/cluster-rippled-servers.md).
|
||||
|
||||
|
||||
## Pares fijos y reservas de pares
|
||||
|
||||
Normalmente, un servidor `rippled` intenta mantener un número saludable de pares, y se conecta automáticamente a pares no confiables hasta un número máximo. Puedes configurar un servidor `rippled` para permanecer conectado a servidores de pares específicos de varias maneras:
|
||||
|
||||
- Utiliza **Pares fijos** para permanecer siempre conectado a pares específicos basado en sus direcciones IP. Esto solo funciona si los pares tienen direcciones IP fijas. Usa el apartado `[ips_fixed]` para configurar pares fijos. Esto es una parte necesaria para [clustering](clustering.md) o [pares privados](#pares-privados). Los pares fijos están definidos en el fichero de configuración, pero los cambios solo se aplican una vez se reinicia el servidor. Los pares fijos son más útiles para mantener servidores conectados si esos servidores son administrados por la misma persona u organización.
|
||||
- Utiliza **Reservas de pares** para priorizar pares específicos. Si tu servidor tiene una reserva de pares para un par específico, entonces tu servidor siempre acepta peticiones de conexión desde ese par incluso si tu servidor está ya en su número máximo de pares conectados. (Esto puede causar que tu servidor _supere_ el número máximo de pares.) Identificas a un par reservado por su [par de claves de nodo](#par-de-claves-de-nodo), así puedes hacerlo incluso para pares con una direcciones IP dinamicas. Las reservas de pares son configurados a través de comandos de administrador y guardados en las bases de datos del servidor, por lo que se pueden ajustar mientras el servidor está online y son salvados durante los reinicios. Las reservas de pares más útiles para conectarse a servidor administrados por diferentes personas u organización. <!-- STYLE_OVERRIDE: prioritize -->
|
||||
|
||||
En los siguientes casos, un servidor `rippled` no se conecta a pares no confiables:
|
||||
|
||||
- Si el servidor es configurado como un [par privado](#pares-privados), se conecta _solo_ a sus pares fijos.
|
||||
- Si el servidor esta ejecutando en [modo solitario][] no se conecta a _ningún_ par.
|
||||
|
||||
|
||||
## Pares privados
|
||||
|
||||
Puedes configurar un servidor `rippled` para actuar como un servidor "privado" para mantener oculta su dirección IP del público general. Esta puede ser una precaución útil contra ataques de denegación de servicio e intentos de intrusión en servidores `rippled` importantes como los validadores de confianza. Para participar en la red peer-to-peer, un servidor privado debe estar configurado para conectarse a al menos un servidor no privado, que transmita sus mensajes al resto de la red.
|
||||
|
||||
**Atención:** Si configuras un servidor privado sin ningún [par fijo](#pares-fijos-y-reservas-de-pares), el servidor no puede conectarse a la red, por lo que no puede conocer el estado de la red, transmitir transacciones o participar en el proceso de consenso.
|
||||
|
||||
Configurar un servidor como un servidor privado tiene varios efectos:
|
||||
|
||||
- El servidor no hace conexiones salientes a otros servidores en la red peer-to-peer a menos que se haya configurado explícitamente para conectarse a esos servidores.
|
||||
- El servidor no acepta conexiones entrantes de otros servidores a menos que se haya configurado explícitamente para aceptar conexiones de esos servidores.
|
||||
- El servidor pide a sus pares directos no revelar su dirección IP a comunicaciones no confiables, incluyendo a la [respuesta de la API del peer crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md). Esto no afecta a las comunicaciones confiables como el [método peers admin][peers method].
|
||||
|
||||
Los servidores siempre piden a sus pares ocultar las direcciones IP de validadores, independientemente de la configuración del servidor privada. Esto ayuda a proteger validadores de ser sobrecargados por ataques de denegación de servicio.
|
||||
|
||||
**Atención:** Es posible modificar el código fuente de un servidor para que ignore esta petición y comparta las direcciones IP de sus pares inmediatos de todos modos. Debes configurar tu servidor privado para que se conecte solo a servidores que sepas que no están modificados de esta manera.
|
||||
|
||||
### Pros y contras de las configuraciones de pares
|
||||
|
||||
Para ser parte del XRP Ledger, un servidor `rippled` debe estar conectado al resto de la red abierta peer-to-peer. A grandes rasgos, hay tres categorías de configuraciones para cómo un servidor `rippled` se conecta a la red:
|
||||
|
||||
- Usando **pares descubiertos**. El servidor se conecta a cualquier servidor no confiable que encuentre y permanece conectado siempre que esos servidores se comporten adecuadamente. (Por ejemplo, no solicitan demasiados datos, sus conexiones de red son estables y parecen estar siguiendo la misma [red](parallel-networks.md).) Esto es lo predeterminado.
|
||||
- Como un **servidor privado utilizando proxies** ejecutado por la misma persona u organización. Los proxies son servidores stock `rippled` (también conectados a pares descubiertos) que mantienen una conexión de emparejamiento fija con el servidor privado.
|
||||
- Como un **servidor privado utilizando hubs públicos**. Esto es similar a utilizar proxies, pero depende de terceros específicos.
|
||||
|
||||
Los pros y contras de cada configuración son los siguientes:
|
||||
|
||||
|
||||
<table>
|
||||
<thead><tr>
|
||||
<th>Configuración</th> <th>Pros</th> <th>Contras</th>
|
||||
</tr></thead>
|
||||
<tbody>
|
||||
<tr><th>Pares descubiertos</th>
|
||||
<td><ul>
|
||||
<li><p>La configuración más simple, con una carga de mantenimiento baja.</p></li>
|
||||
<li><p>Crea la oportunidad para una gran cantidad de conexiones directas de pares. Tener más pares directos tiene varios beneficios. Tu servidor puede <a href="ledger-history.html#recuperar-el-histórico">recuperar histórico</a> de múltiples pares en paralelo, tanto al sincronizar como al rellenar el histórico. Como no todos los pares mantienen el histórico completo, tener acceso a una gama más amplia de datos históricos.</p></li>
|
||||
<li><p>Reduce la posibilidad de desconexión de la red porque tu servidor puede reemplazar los pares desconectados con otros nuevos.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>No te permite seleccionar los pares de tu servidor, lo que significa que no tienes idea de si tus pares pueden decidir actuar maliciosamente. Aunque los servidores `rippled` están diseñados para protegerse contra pares maliciosos, siempre existe el riesgo de que los pares maliciosos puedan atacar fallos en el software para afectar a tu servidor.</p></li>
|
||||
<li><p>Los pares de tu servidor pueden desconectarse o cambiar a menudo.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>Servidor privado utilizando proxies</th>
|
||||
<td><ul>
|
||||
<li><p>Configuración más segura y confiable cuando se implementa correctamente.</p></li>
|
||||
<li><p>Tan confiable y redundante como quieras hacerla.</p></li>
|
||||
<li><p>Puedes optimizar el rendimiento del servidor privado con <a href="clustering.html">clustering</a>.</p></li>
|
||||
<li><p>Te permite crear tantas conexiones directas de pares como desees. Tu servidor privado puede <a href="ledger-history.html#recuperar-el-histórico">obtener histórico</a> desde múltipes pares en paralelo. Dado que administras los pares, también puedes controlar cuanto histórico del ledger cada par puede mantener.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>Carga de mantenimiento y costos más altos debido a la ejecución de múltiples servidores.</p></li>
|
||||
<li><p>No elimina por completo la posibilidad de interrupciones en la conexión de pares. No importa cuántos proxies ejecutes, si todos existen en el mismo rack de servidores, entonces una interrupción de red o de luz puede afectar a todos ellos.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>Servidor privado utilizando hubs públicos</th>
|
||||
<td><ul>
|
||||
<li><p>Carga de mantenimiento baja con una pequeña cantidad de configuración.</p></li>
|
||||
<li><p>Proporciona acceso a conexiones seguras a la red.</p></li>
|
||||
<li><p>En comparación con la conexión utilizando proxies, es menos probable que cause que tu servidor privado se desconecte de la red debido a una interrupción simultánea de pares.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>Depende de terceros con una alta reputación para mantenerse confiable.</p></li>
|
||||
<li>
|
||||
<p>Puede hacer que tu servidor se desconecte de la red si los hubs públicos en los que confías están demasiado ocupados. Debido a la naturaleza de los hubs públicos, son los más populares y es posible que no puedan mantener una conexión estable abierta para todos.</p>
|
||||
<p>Para evitar este problema, usa más hubs públicos; cuanto más, mejor. También puede ayudar usar hubs no predeterminados, que son menos propensos a estar ocupados.</p>
|
||||
</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Configurando un servidor privado
|
||||
|
||||
Para configurar tu servidor como un servidor privado, establece la opción `[peer_private]` a `1` en el fichero de configuración. Para intrudciones más detalladas, ver [Configurar un servidor privado](../../infrastructure/configuration/peering/configure-a-private-server.md).
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- [Redes paralelas](parallel-networks.md)
|
||||
- **Tutoriales:**
|
||||
- [Cluster de servidores rippled](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
|
||||
- [Configurar un servidor privado](../../infrastructure/configuration/peering/configure-a-private-server.md)
|
||||
- [Configurar el Peer Crawler](../../infrastructure/configuration/peering/configure-the-peer-crawler.md)
|
||||
- [Redireccionar puertos para pares](../../infrastructure/configuration/peering/forward-ports-for-peering.md)
|
||||
- [Conectarse manualmente a un par específico](../../infrastructure/configuration/peering/manually-connect-to-a-specific-peer.md)
|
||||
- [Establecer número máximo de pares](../../infrastructure/configuration/peering/set-max-number-of-peers.md)
|
||||
- [Utilizar la reserva de pares](../../infrastructure/configuration/peering/use-a-peer-reservation.md)
|
||||
- **Referencias:**
|
||||
- [método peers][]
|
||||
- [método peer_reservations_add][]
|
||||
- [método peer_reservations_del][]
|
||||
- [método peer_reservations_list][]
|
||||
- [método connect][]
|
||||
- [método fetch_info][]
|
||||
- [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
html: rippled-server-modes.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Aprende sobre los modos de servidor rippled, incluyendo servidores stock, servidores validadores y servidores que se ejecutan en modo solitario.
|
||||
labels:
|
||||
- Servidor principal
|
||||
---
|
||||
# Modos de servidor rippled
|
||||
|
||||
El software del servidor `rippled` puede ejecutarse en varios modos dependiendo de su configuración, incluyendo:
|
||||
|
||||
- [**Modo P2P**](#modo-p2p) - Este es el modo principal del servidor: sigue la red peer-to-peer, procesa transacciones, y mantiene cierta cantidad de [histórico del ledger](ledger-history.md). Este modo se puede configurar para alguno o todos los siguientes roles:
|
||||
- [**Validador**](#validadores) - Ayuda a asegurar la red participando en el consenso.
|
||||
- [**Servidor API**](#servidores-api) - Proporciona [acceso API](../../tutorials/http-websocket-apis/build-apps/get-started.md) para leer datos del ledger compartido, enviar transacciones, y mirar la actividad en el ledger. Opcionalmente, puede ser un [**servidor full history**](#servidores-full-history), el cual guarda un registro completo de transacciones y el histórico del ledger.
|
||||
- [**Servidor hub**](#hubs-públicos) - Transmite mensajes entre muchos otros miembros de la red peer-to-peer.
|
||||
- [**Modo Reporting**](#modo-reporting) - Un modo especializado para servir consultas API desde una base de datos relacional. No participa en la red peer-to-peer, por lo que necesitas ejecutar un servidor en modo P2P y conectarle el servidor modo reporting usando una conexión gRPC de confianza.
|
||||
- [**Modo solitario**](#modo-solitario) - Un modo offline para pruebas. No se conecta a la red peer-to-peer ni usa consenso.
|
||||
|
||||
Tambien puedes ejecutar el ejecutable `rippled` como una aplicación cliente para acceder [APIs `rippled`](../../references/http-websocket-apis/index.md) localmente. (Dos instancias del mismo binario pueden ejecutarse uno al lado del otro en este caso; uno como un servidor, y el otro ejecutándose brevemente como cliente y luego apagarlo.)
|
||||
|
||||
Para más información sobre los comandos que ejecutar `rippled` en cada uno de estos modos, ver la [Referencia de línea de comandos](../../infrastructure/commandline-usage.md).
|
||||
|
||||
|
||||
## Modo P2P
|
||||
|
||||
El Modo P2P es el modo principal y predeterminado del servidor `rippled`, y puede manejar casi cualquier cosa que desees que haga tu servidor. Estos servidores forman una red peer-to-peer que procesa transacciones y mantiene el estado compartido del XRP Ledger. Si deseas enviar transacciones, leer datos del ledger o participar de otra manera en la red, tus solicitudes deben pasar por un servidor en Modo P2P en algún momento.
|
||||
|
||||
Los servidores en Modo P2P también pueden configurarse para proporcionar funcionalidades adicionales. Un servidor ejecutando en Modo P2P con un archivo de configuración mínimamente modificado también se llama un servidor de stock o _stock server_. Otras configuraciones incluyen:
|
||||
|
||||
- [Validador](#validadores)
|
||||
- [Servidor API](#servidores-api)
|
||||
- [Hubs públicos](#hubs-publicos)
|
||||
|
||||
Los servidores Modo P2P se conecta a [Mainnet](parallel-networks.md) por defecto.
|
||||
|
||||
|
||||
### Servidores API
|
||||
|
||||
Todos los servidores en Modo P2P proporcionan [APIs](../../references/http-websocket-apis/index.md) para propósitos como enviar transacciones, verificar balances y configuraciones, y administrar el servidor. Si consultas el XRP Ledger para obtener datos o enviar transacciones para uso comercial, puede ser útil [ejecutar tu propio servidor](index.md#razones-por-las-que-ejecutar-tu-propio-servidor).
|
||||
|
||||
#### Servidores Full History
|
||||
|
||||
A diferencia de algunas otras blockchains, el XRP Ledger no requiere que los servidores tengan un historial completo de transacciones para conocer el estado actual y procesar nuevas transacciones. Como operador de servidor, tú decides cuánto [histórico del ledger](ledger-history.md) almacenar en un momento dado. Sin embargo, un servidor en Modo P2P solo puede responder a solicitudes de API utilizando el historial del ledger que tiene disponible localmente. Por ejemplo, si conservas seis meses de historial, tu servidor no puede describir el resultado de una transacción de hace un año. Los servidores API con histórico completo o [full history](ledger-history.md#full-history) pueden informar de todas las transacciones y balances desde el inicio del XRP Ledger.
|
||||
|
||||
|
||||
### Hubs públicos
|
||||
|
||||
Un servidor hub es un servidor en Modo P2P con muchas [conexiones del protocolo de pares](peer-protocol.md) a otros servidores. Los servidores hub, especialmente los _hubs públicos_ que permiten conexiones desde Internet abierto, ayudan a la red del XRP Ledger a mantener una conectividad eficiente. Los hubs públicos exitosos encarnan las siguientes características:
|
||||
|
||||
- Buen ancho de banda.
|
||||
|
||||
- Conexiones con muchos pares confiables.
|
||||
|
||||
- Capacidad para transmitir mensajes de maneja confiable.
|
||||
|
||||
Para configurar tu servidor como un hub, aumenta el número máximo de pares permitidos y asegúrate de haber [redireccionado los puertos apropiados](../../infrastructure/configuration/peering/forward-ports-for-peering.md) a través de tu firewall y enrutador de NAT (traducción de dirección de red) según corresponda.
|
||||
|
||||
### Validadores
|
||||
|
||||
La robustez del XRP Ledger depende de una red interconectada de _validadores_ que confían mutuamente en algunos otros validadores para _no colisionar_. Además de procesar cada transacción y calcular el estado del ledger exactamente como otros servidores en Modo P2P, los validadores participan activamente en el [protocolo de consenso](../consensus-protocol/index.md). Si tú o tu organización dependen del XRP Ledger, es de tu interés contribuir al proceso de consenso ejecutando _un_ servidor como validador.
|
||||
|
||||
La validación utiliza solo una pequeña cantidad de recursos informáticos, pero no hay mucho beneficio para una sola entidad u organización en ejecutar varios validadores porque hacerlo no proporciona más protecciones contra las colisiones. Cada validador se identifica con un par de claves criptográficas único que debe ser gestionado cuidadosamente; múltiples validadores no deben compartir un par de claves. Por estas razones, la validación está desactivada de forma predeterminada.
|
||||
|
||||
Puedes habilitar de forma segura la validación en un servidor que también se utiliza para otros fines; este tipo de configuración se llama un _servidor multiuso_. Alternativamente, puedes ejecutar un _validador dedicado_ que no realice otras tareas, posiblemente en un [cluster](clustering.md) con otros servidores `rippled` en Modo P2P.
|
||||
|
||||
Para más información sobre como ejecutar un validador, ver [Ejecutar `rippled` como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).
|
||||
|
||||
|
||||
## Modo reporting
|
||||
|
||||
|
||||
El modo reporting es un modo especializado para servir solicitudes API de manera más eficiente. En este modo, el servidor obtiene los datos del ledger validados más recientes a través de [gRPC](../../infrastructure/configuration/configure-grpc.md) desde un servidor `rippled` separado en Modo P2P, luego carga esos datos en una base de datos relacional ([PostgreSQL](https://www.postgresql.org/)). El servidor en modo reporting no participa directamente en la red peer-to-peer, aunque puede reenviar solicitudes como el envío de transacciones al servidor en Modo P2P que utiliza.
|
||||
|
||||
Varios servidores en modo reporting pueden compartir acceso a una base de datos PostgreSQL y a un clúster [Apache Cassandra](https://cassandra.apache.org/) para servir una gran cantidad de historial sin que cada servidor necesite una copia redundante de todos los datos. Los servidores en modo reporting proporcionan estos datos a través de las mismas [`rippled` APIs](../../references/http-websocket-apis/index.md) con algunos cambios leves para adaptarse a las diferencias en cómo almacenan los datos subyacentes.
|
||||
|
||||
Especialmente, los servidores en modo reporting no informan sobre datos pendientes de validación del ledger o transacciones no validadas. Esta limitación es relevante para ciertos casos de uso que dependen de un acceso rápido a datos en flujo, como realizar arbitraje en el [exchange descentralizado](../tokens/decentralized-exchange/index.md).
|
||||
|
||||
<!-- TODO: link setup steps for Reporting Mode when those are ready -->
|
||||
|
||||
|
||||
## Modo solitario
|
||||
|
||||
En el modo solitario, el servidor opera sin conectarse a la red y sin participar en el proceso de consenso. Sin el proceso de consenso, debes avanzar manualmente el ledger y no se hace ninguna distinción entre "cerrado" y "validado" ledgers. Sin embargo, el servidor sigue proporcionando acceso a la API y procesa transacciones de la misma manera. Esto te permite:
|
||||
|
||||
- [Probar los efectos de enmiendas](../../infrastructure/testing-and-auditing/test-amendments.md) antes de que esas enmiendas hayan entrado en efecto en toda la red descentralizada.
|
||||
- [Crear un nuevo ledger génesis](../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md) desde el inicio.
|
||||
- [Cargar una versión de ledger existente](../../infrastructure/testing-and-auditing/load-a-saved-ledger-in-stand-alone-mode.md) desde el disco, luego reproducir transacciones específicas para recrear sus resultados y probar otras posibilidades.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Tutoriales:**
|
||||
- [Configurar `rippled`](../../infrastructure/configuration/index.md)
|
||||
- [Usar rippled en modo solitario](../../infrastructure/testing-and-auditing/index.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
html: the-clio-server.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Clio es un servidor XRP Ledger optimizado para llamadas API.
|
||||
---
|
||||
# El servidor Clio
|
||||
|
||||
Clio es un servidor API del XRP Ledger optimizado para llamadas de WebSocket o HTTP API para datos del ledger validados.
|
||||
|
||||
Un servidor Clio no se conecta a la red peer-to-peer. En su lugar, extrae datos de un servidor `rippled` especifico que está conectado a la red P2P. Al manejar las llamadas API de manera eficiente, los servidores Clio pueden ayudar a reducir la carga en los servidores `rippled` que se ejecutan en modo P2P.
|
||||
|
||||
Clio almacena datos históricos del ledger y transacciones validadas en un formato eficiente de espacio, utilizando hasta 4 veces menos espacio que `rippled`. Clio utiliza Cassandra o ScyllaDB, lo que permite una capacidad de lectura escalable. Multiples servidores Clio pueden compartir acceso al mismo conjunto de datos, lo que le permite construir un clúster altamente disponible de servidores Clio sin necesidad de almacenamiento o cálculo de datos redundantes o computación
|
||||
|
||||
Clio requiere acceso a un servidor `rippled`, que pueda ejecutarse en la misma máquina que Clio o por separado.
|
||||
|
||||
Mientras que Clio ofrece las [APIs HTTP / WebSocket](../../references/http-websocket-apis/index.md) completas, por defecto, solo devuelve datos validados. Para cualquier solicitud que requiera acceso a la red P2P, Clio reenvía automáticamente la solicitud al servidor `rippled` en la red P2P y devuelve la respuesta.
|
||||
|
||||
## ¿Por qué debería ejecutar un servidor Clio?
|
||||
|
||||
Hay multitud de razones por las que podrías querer ejecutar tu propio servidor Clio, pero la mayoría se pueden resumir en: carga reducida en el/los servidor(es) `rippled` conectado(s) a la red P2P, menor uso de memoria y sobrecarga de almacenamiento, escalabilidad horizontal más fácil y mayor rendimiento para las solicitudes API.
|
||||
|
||||
* Carga reducida en el/los servidor(es) `rippled` - Un servidor Clio no se conecta a la red peer-to-peer. Utiliza gRPC para obtener datos validados de uno o más servidores `rippled` de confianza que están conectados a la red P2P. Por lo tanto, un servidor Clio maneja las solicitudes de manera más eficiente y reduce la carga en los servidores `rippled` que se ejecutan en modo P2P.
|
||||
|
||||
* Menor uso de memoria y sobrecarga de almacenamiento - Clio utiliza Cassandra como base de datos y almacena datos en un formato eficiente en espacio, utilizando hasta 4 veces menos espacio que `rippled`.
|
||||
|
||||
* Escalabilidad horizontal más fácil - Múltiples servidores Clio pueden compartir acceso al mismo conjunto de datos, lo que le permite construir un clúster altamente disponible de servidores Clio.
|
||||
|
||||
* Mayor rendimiento para las solicitudes API - Un servidor Clio extrae datos validados de uno o más servidores `rippled` confiables y almacena estos datos de manera eficiente. Por lo tanto, maneja las llamadas API de manera eficiente, lo que resulta en un mayor rendimiento y, en algunos casos, una latencia más baja también.
|
||||
|
||||
|
||||
## ¿Cómo funciona un servidor Clio?
|
||||
|
||||
[{% inline-svg file="/docs/img/clio-basic-architecture.svg" /%}](/docs/img/clio-basic-architecture.svg "Figura 1: ¿Cómo funciona un servidor Clio?")
|
||||
|
||||
Cuando un servidor Clio almacena datos del ledger validados, como metadatos de transacciones, estados de cuentas y encabezados de ledger, en un almacén de datos persistente.
|
||||
|
||||
Cuando un servidor Clio recibe una solicitud API, busca datos en estos almacenes de datos. Para solicitudes que requieren datos de la red P2P, el servidor Clio reenvía la solicitud a un servidor P2P y luego pasa la respuesta de vuelta al cliente.
|
||||
|
||||
Clio **siempre** reenvía a `rippled` si alguna de las siguientes condiciones es verdadera:
|
||||
|
||||
- `ledger_index` está establecido a `current` o `closed`.
|
||||
- `accounts`, `queue` o `full` están establecidos en `true` para la API de `ledger`.
|
||||
- `queue` está establecido en `true` para la API de `account_info`.
|
||||
- El método solicitado de API (`"command"`) es `submit`, `submit_multisigned`, `fee`, `ledger_closed`, `ledger_current`, `ripple_path_find`, `manifest`, `channel_authorize` o `channel_verify`.
|
||||
|
||||
## Ver también
|
||||
|
||||
- [Código fuente Clio](https://github.com/XRPLF/clio)
|
||||
- **Tutoriales:**
|
||||
- [Instalar servidor Clio en Ubuntu](../../infrastructure/installation/install-clio-on-ubuntu.md)
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
html: transaction-censorship-detection.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: El XRP Ledger proporciona un detector de censura de transacciones automatizado que está disponible en todos los servidores rippled.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Detección de censura de transacciones
|
||||
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}Nuevo en: rippled 1.2.0{% /badge %}
|
||||
|
||||
El XRP Ledger está diseñado para ser resistente a la censura. En apoyo a este diseño, el XRP Ledger proporciona un detector automatizado de censura de transacciones que está disponible en todos los servidores `rippled`, permitiendo que todos los participantes vean si la censura está afectando a la red.
|
||||
|
||||
Mientras un servidor `rippled` está sincronizado con la red, el detector rastrea todas las transacciones que deberían haber sido aceptadas en la última ronda de [consensus](../consensus-protocol/index.md) e incluidas en el último ledger validado. El detector emite mensajes de registro de severidad creciente cuando ve transacciones que no han sido incluidas en un ledger validado después de varias rondas de consenso.
|
||||
|
||||
|
||||
|
||||
## ¿Cómo funciona?
|
||||
|
||||
A alto nivel, así es cómo el detector de censura de transacciones funciona:
|
||||
|
||||
1. El detector agrega todas las transacciones en la propuesta de consenso inicial del servidor al rastreador.
|
||||
|
||||
2. Al cierre de la ronda de consenso, el detector elimina todas las transacciones incluidas en el ledger validado resultante del rastreador.
|
||||
|
||||
3. El detector emite un [mensaje de advertencia](#ejemplo-de-mensaje-de-advertencia) en el registro para cualquier transacción que permanezca en el rastreador durante 15 ledgers, mostrándola como una transacción potencialmente censurada. La presencia de la transacción en el rastreador en este momento significa que no ha sido incluida en un ledger validado después de 15 rondas de consenso. Si la transacción permanece en el rastreador durante otros 15 ledgers, el detector emite otro mensaje de advertencia en el registro.
|
||||
|
||||
Mientras la transacción permanezca en el rastreador, el detector continuará emitiendo un mensaje de advertencia en el registro cada 15 ledgers, hasta cinco mensajes de advertencia. Después del quinto mensaje de advertencia, el detector emite un [mensaje de error](#ejemplo-de-mensaje-de-error) final en el registro y luego deja de emitir mensajes de advertencia y error.
|
||||
|
||||
Si ves estos mensajes en el registro de tu servidor rippled, debes investigar por qué otros servidores no están incluyendo la transacción, comenzando con la suposición de que la causa es más probable que sea un [falso positivo](#potenciales-falsos-positivos) (error inocente) que una censura maliciosa.
|
||||
|
||||
## Ejemplo de mensaje de advertencia
|
||||
|
||||
Esto es un ejemplo de mensaje de advertencia emitido por el detector de censura de transacciones de que la transacción E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 permaneciese en el rastreador por 15 ledgers, desde el ledger 18851530 hasta el ledger 18851545.
|
||||
|
||||
```text
|
||||
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
|
||||
```
|
||||
|
||||
|
||||
## Ejemplo de mensaje de error
|
||||
|
||||
Este es un ejemplo de mensaje de error emitido por el detector de censura de transacciones después de que la transacción E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 permaneciese en el rastreador por 75 ledgers (5 conjuntos de 15 ledgers), desde el ledger 18851530 hasta el ledger 18851605.
|
||||
|
||||
```text
|
||||
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
|
||||
```
|
||||
|
||||
|
||||
## Potenciales falsos positivos
|
||||
|
||||
El detector de censura de transacciones puede emitir falsos positivos en ciertos escenarios. En este caso, un falso positivo significa que el detector ha marcado una transacción que ha permanecido en el rastreador durante 15 ledgers o más, pero por razones inocentes.
|
||||
|
||||
Aquí hay algunos escenarios que podrían causar que el detector emita mensajes de falsos positivos:
|
||||
|
||||
- Tu servidor está ejecutando una compilación con código diferente al resto de la red. Esto puede hacer que tu servidor aplique transacciones de manera diferente, lo que resulta en falsos positivos. Si bien este tipo de falsos positivos es poco probable en general, es crucial que ejecutes una versión compatible del servidor principal del XRP Ledger.
|
||||
|
||||
- Tu servidor está fuera de sincronización con la red y aún no lo ha notado.
|
||||
|
||||
- Los servidores en la red, incluido posiblemente tu propio servidor, tienen un error que les hace transmitir transacciones de manera inconsistente a otros servidores en la red.
|
||||
|
||||
Actualmente, no se conocen errores que causen este comportamiento inesperado. Sin embargo, si ves el impacto de lo que sospechas que es un error, considera reportarlo al programa [Ripple Bug Bounty](https://ripple.com/bug-bounty/).
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Principio de consenso y reglas](../consensus-protocol/consensus-principles-and-rules.md)
|
||||
- [Cola de transacciones](../transactions/transaction-queue.md)
|
||||
- **Tutoriales:**
|
||||
- [Envío confiable de transacciones](../transactions/reliable-transaction-submission.md)
|
||||
- [Entendiendo los mensajes de registro](../../infrastructure/troubleshooting/understanding-log-messages.md)
|
||||
- **Referencias:**
|
||||
- [Resultados de transacciones](../../references/protocol/transactions/transaction-results/index.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
Reference in New Issue
Block a user