diff --git a/@l10n/es-ES/CODE_OF_CONDUCT.md b/@l10n/es-ES/CODE_OF_CONDUCT.md
index c8da32b3cf..ab368fcefa 100644
--- a/@l10n/es-ES/CODE_OF_CONDUCT.md
+++ b/@l10n/es-ES/CODE_OF_CONDUCT.md
@@ -8,19 +8,19 @@ Con el fin de fomentar un ambiente abierto y acogedor, nosotros, como contribuid
Ejemplos de comportamiento que contribuyen a crear un ambiente positivo incluyen:
-* Utilizar lenguaje acogedor e inclusivo
-* Ser respetuoso con los diferentes puntos de vista y experiencias
-* Saber aceptar las críticas constructivas
-* Centrarse en lo que es lo mejor para la comunidad
-* Mostrar empatía hacia otros miembros de la comunidad
+- Utilizar lenguaje acogedor e inclusivo
+- Ser respetuoso con los diferentes puntos de vista y experiencias
+- Saber aceptar las críticas constructivas
+- Centrarse en lo que es lo mejor para la comunidad
+- Mostrar empatía hacia otros miembros de la comunidad
Ejemplos de comportamiento que no contribuyen a crear un ambiente positivo incluyen:
-* Utilizar un lenguaje o imágenes sexualizadas y atención o insinuaciones sexuales no deseadas
-* Trolear, comentario insultantes/peyorativos y ataques personales o políticos
-* Acoso público o en privado
-* Publicar información privada de otras personas, así cómo direcciones físicas o electrónicas, sin permiso explícito
-* Cualquier otra conducta que pueda ser razonablemente considerada inapropiada en un sentido profesional
+- Utilizar un lenguaje o imágenes sexualizadas y atención o insinuaciones sexuales no deseadas
+- Trolear, comentario insultantes/peyorativos y ataques personales o políticos
+- Acoso público o en privado
+- Publicar información privada de otras personas, así cómo direcciones físicas o electrónicas, sin permiso explícito
+- Cualquier otra conducta que pueda ser razonablemente considerada inapropiada en un sentido profesional
## Nuestras responsabilidades
diff --git a/@l10n/es-ES/CONTRIBUTING.md b/@l10n/es-ES/CONTRIBUTING.md
index 4774d8e46e..48d5721c96 100644
--- a/@l10n/es-ES/CONTRIBUTING.md
+++ b/@l10n/es-ES/CONTRIBUTING.md
@@ -1,3 +1,3 @@
# Contribuir
-Para obtener información sobre cómo contribuir a este repositorio, consulta [Contribute Documentation (XRPL.org)](https://xrpl.org/es_ES/contribute-documentation.html).
\ No newline at end of file
+Para obtener información sobre cómo contribuir a este repositorio, consulta [Contribute Documentation (XRPL.org)](https://xrpl.org/es_ES/contribute-documentation.html).
diff --git a/@l10n/es-ES/about/faq.md b/@l10n/es-ES/about/faq.md
index e428959875..ea00546e6e 100644
--- a/@l10n/es-ES/about/faq.md
+++ b/@l10n/es-ES/about/faq.md
@@ -1,11 +1,13 @@
---
seo:
- description: Respuestas a preguntas frecuentes sobre el XRP Ledger, el ecosistema XRPL y la comunidad.
+ description: Respuestas a preguntas frecuentes sobre el XRP Ledger, el ecosistema XRPL y la comunidad.
subtitle: Respuestas a tus preguntas XRPL
labels:
- Blockchain
---
+
###### FAQ
+
# Respuestas a Tus Preguntas XRPL
@@ -38,27 +40,22 @@ Todos los nodos garantizan que las transacciones cumplen los requisitos del prot
Ver [Consenso](../docs/concepts/consensus-protocol/index.md) para más información sobre el proceso de consenso.
-
#### ¿Cuánto cuesta mantener un validador?
Mantener un validador no requiere de comisiones o XRP. Es comparable al gasto de ejecutar un servidor de correo electrónico en términos de uso de electricidad.
-
#### ¿Qué son Las Listas de Nodos Únicos (UNLs)?
Las UNLs son las listas de validadores que un participante determinado cree que no conspirarán para defraudarle. Cada operador de servidor puede elegir su propia UNL, generalmente basándose en un cojunto determinado proporcionado por un publicador de confianza. (La lista predeterminada de un publicador a veces es llamada UNL predeterminada, o _dUNL_.)
-
#### ¿Qué UNL debería escoger?
Dado que cualquiera puede montar un validador, la carga de elegir un conjunto confiable de validadores recae sobre los participantes. Actualmente, la XRP Ledger Foundation y Ripple publican listas predeterminadas recomendadas de valiadores de alta calidad, basadas en desesmpeño pasado, identidades comprobadas, y políticas de IT responsables. Sin embargo, cada participante de la red puede elegir qué validadores considera confiables y no necesita seguir a uno de los publicadores mencionados anteriormente.
-
#### Si Ripple recomienda la adopción de su UNL, ¿Esto no crea un sistema centralizado?
No. Cada participante elige directa o indirectamente su UNL. Si Ripple dejase de operar o actuase de manera maliciosa, los participantes pueden cambiar sus UNLs para usar una lista de un publicador diferente.
-
#### ¿Cuál es la estructura de incentivos para los validadores?
El principal incentivo para ejecutar un validador es preservar y proteger el funcionamiento estable y la evolución sensata de la red. Son los validadores quienes deciden la evolución del XRP Ledger, por lo que cualquier negocio que utilice o dependa del XRP Ledger tiene un incentivo inherente para garantizar la confiabilidad y estabilidad de la red. Los validadores también se ganan el respeto y la buena voluntad de la comunidad al contribuir de esta manera.
@@ -67,12 +64,10 @@ Si ejecutas un servidor XRP Ledger para participar en la red, el costo y el esfu
Para ver ejemplos de cómo los incentivos pueden distorsionar el comportamiento de validación, lee sobre [valor extraíble del minero (MEV en inglés)](https://arxiv.org/abs/1904.05234).
-
#### ¿Pueden las instituciones financieras establecer validadores de transacciones para ayudarlas a cumplir estándares y requisitos institucionales específicos?
No, las instituciones no pueden configurar políticas de validación personalizadas para elegir permitir algunas transacciones y rechazar otras. Los validadores siguen el protocolo o no. Si el software no sigue las reglas del protocolo, no funciona. Por lo tanto, no se recomienda que las instituciones busquen implementaciones personalizadas sin experiencia interna.
-
#### ¿Qué pasa si más del 20% de los nodos de la red no están de acuerdo con la mayoría? ¿Cómo se elige la versión final del ledger?
Normalmente, si hay una disputa sobre la validez de una transacción, esa transacción se pospone hasta que la mayoría pueda llegar a un acuerdo. Pero si más del 20% de la red no siguiera las mismas reglas de protocolo que la mayoría, la red se detendría temporalmente. Podría reanudarse cuando los participantes reconfiguren sus UNL en función de aquellos que quieran llegar a un consenso entre ellos. Se desea este retraso temporal en el procesamiento en lugar de duplicar el gasto.
@@ -83,7 +78,6 @@ Sin embargo, sólo puede haber una última versión del ledger _validated_ en un
Para obtener más información sobre cómo se comporta el mecanismo de consenso del XRP Ledger en situaciones adversas, consulta [Protecciones de consenso contra ataques y modos de fallo](../docs/concepts/consensus-protocol/consensus-protections.md).
-
#### ¿El XRP Ledger tiene un proceso formal para añadir validadores?
No, un proceso formal para agregar validadores no es compatible con XRP Ledger, porque es un sistema sin autoridad central.
@@ -92,28 +86,24 @@ Los publicadores de UNL predeterminados individuales establecen sus propias pol
Para recomendaciones y mejores prácticas, consulta [Ejecutar `rippled` como validador](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).
-
#### Si la dUNL tiene lmayor influencia en la red, ¿quiere decir que XRPL es centralizado?
+
Los validadores pueden optar por no utilizar la dUNL o cualquier UNL ampliamente utilizada. Cualquiera puede crear una nueva UNL en cualquier momento.
Puede haber varias UNL en uso en la misma red. Cada operador puede personalizar la UNL de su propio servidor o elegir seguir una lista recomendada diferente. Todos estos servidores todavía pueden ejecutar la misma cadena y llegar a un consenso entre sí.
Sin embargo, si tu UNL no coincide lo suficiente con las UNL utilizadas por otros, existe el riesgo de que su servidor se separe (fork) del resto de la red. Siempre que tu UNL tenga > 90 % de superposición con la utilizada por las personas con las que transaccionas, estás completamente a salvo de bifurcarte. Si tiene menos superposición, es posible que aún puedas seguir la misma cadena, pero las posibilidades de bifurcarte aumentan con una menor superposición, peor conectividad de red y la presencia de validadores maliciosos o poco confiables en tu UNL.
-
## Papel de XRP
-
#### ¿Cuál es el proposito de XRP?
XRP se creó como el activo nativo de XRP Ledger para potenciar una nueva generación de pagos digitales: más rápidos, más ecológicos y más baratos que cualquier activo digital anterior. También sirve para proteger el ledger del spam y para [conectar divisas](../docs/concepts/tokens/decentralized-exchange/autobridging.md) en el exchange descentralizado del XRP Ledger, cuando hacerlo es beneficioso para los usuarios. Con el tiempo, la comunidad XRP Ledger ha sido pionera en nuevos [casos de uso](/about/uses) para XRP, al igual que el propio XRP Ledger.
-
#### ¿Cómo responde el XRP Ledger al flood de transaciones?
El XRP Ledger está diseñado para establecer el [coste de transacción](../docs/concepts/transactions/transaction-cost.md) dinámicamente en función de la demanda como una medida antispam. El impacto de cualquier posible manipulación de XRP es minimizado a medida que la red crece, crece la capitalización y crece el volumen de transacciones.
-
#### ¿Qué ocurre con el lavado de dinero y la actividad económica sospechosa?
@@ -124,10 +114,8 @@ Ripple se compromete a monitorear e informar cualquier indicador AML en la red X
[XRP Forensics / xrplorer](https://xrplorer.com/) mantiene una lista de asesoramiento para rastrear y minimizar el lavado de dinero, las estafas, el fraude y el uso ilícito del XRP Ledger. Los exchanges y otros proveedores de servicios pueden utilizar este servicio para prevenir y reaccionar ante delitos financieros.
-
## Consideraciones de seguridad
-
#### ¿Cuál es el proceso para revisar las contribuciones de código de terceros?
El proceso de contribución de código comienza cuando un desarrollador abre una [pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) a un repositorio de código fuente como el [repositorio `rippled`](https://github.com/xrplf/rippled/), que contiene la implementación de referencia de Ripple del núcleo del servidor y del protocolo de XRP Ledger.
@@ -136,7 +124,6 @@ Este pull request activa pruebas unitarias y de integración automatizadas, así
Una vez que el pull request pasa las pruebas automatizadas y recibe la aprobación de los revisores, un [mantenedor del repositorio](https://opensource.guide/best-practices/) confiable puede prepararlo para su inclusión en la próxima versión beta.
-
#### ¿Ripple posee o controla el XRP Ledger o la red XRP Ledger?
No, Ripple no posee ni controla el XRP Ledger o la red XRP Ledger.
@@ -145,7 +132,6 @@ Ripple contribuye a una implementación de referencia del nucleo del servidor de
Varias entidades publican listas de validadores recomndadados (UNLs). Desde julio de 2023, Ripple mantiene solo uno de los 35 validadores que están en la UNL por defecto.
-
#### ¿El XRP Ledger distingue entre el código base para la validación y el del software del usuario?
Sí. Hay varias [librerías de cliente para XRP Ledger](../docs/references/client-libraries.md) que están destinadas a desarrolladores de software de usuario. Estas librerias tienen distintos códigos base y repositorios del [núcleo del servidor XRP Ledger](../docs/concepts/networks-and-servers/index.md) que alimenta la red y valida las transacciones.
diff --git a/@l10n/es-ES/about/privacy-policy.md b/@l10n/es-ES/about/privacy-policy.md
index 7033063c32..9a9c8e4793 100644
--- a/@l10n/es-ES/about/privacy-policy.md
+++ b/@l10n/es-ES/about/privacy-policy.md
@@ -1,8 +1,9 @@
---
seo:
- title: Política de privacidad
- description: Esta política describe cómo MTU XRP Ledger Trust respeta tu privacidad y detalla la recopilación, uso, y divulgación de los datos involucrados en el uso de este servicio.
+ title: Política de privacidad
+ description: Esta política describe cómo MTU XRP Ledger Trust respeta tu privacidad y detalla la recopilación, uso, y divulgación de los datos involucrados en el uso de este servicio.
---
+
# Política de privacidad de XRPL.org
Última actualización: 20 de enero, 2023
@@ -13,14 +14,14 @@ MTU XRP Ledger Trust (“MTU XRP Ledger Trust”, "Nosotros"", "Nuestro") respet
Para los fines de esta Política de Privacidad:
-* _Compañía_ - (referida como "MTU XRP Ledger Trust", "Nosotros", "Nuestro" en esta política) se refiere a XRPL.org
-* _Cookies_ - son pequeños ficheros que se colocan en tu ordenador, dispositivo móvil o cualquier otro dispositivo por un sitio web, conteniendo detalles de tu historial de navegación en ese sitio web entre sus muchos usos.
-* _Dispositivo_ - significa cualquier dispositivo que puede acceder al servicio, como un ordenador, un teléfono móvil o una tablet digital.
-* _Datos personales_ - es cualquier información que se relacione con un usuario identificado o identificable.
-* _Servicio_ - se refiere a este sitio web XRPL.org.
-* _Proveedor de servicios_ - significa cualquier persona normal o jurídica que procesa los datos en nombre de MTU XRP Ledger Trust. Se refiere a tercaras compañías o individuos contratados por MTU XRP Ledger Trust para facilitar el Servicio, para proveer el Servicio en nombre de MTU XRP Ledger Trust, para realizar servicios relacionados con el Servicio o para asistir a MTU XRP Ledger Trust analizando como el Servicio es utilizado.
-* _Datos de Uso_ - se refiere a datos recopilados automáticamente, generados por el uso del Servicio o la infraestructura del Servicio en sí (por ejemplo, la duración de una página visitada).
-* _Tú_ - significa el individuo que accede o usa el Servicio, o MTU XRP Ledger Trust, u otra entidad legal en nombre de la cual dicho individuo accede al Servicio, según corresponda.
+- _Compañía_ - (referida como "MTU XRP Ledger Trust", "Nosotros", "Nuestro" en esta política) se refiere a XRPL.org
+- _Cookies_ - son pequeños ficheros que se colocan en tu ordenador, dispositivo móvil o cualquier otro dispositivo por un sitio web, conteniendo detalles de tu historial de navegación en ese sitio web entre sus muchos usos.
+- _Dispositivo_ - significa cualquier dispositivo que puede acceder al servicio, como un ordenador, un teléfono móvil o una tablet digital.
+- _Datos personales_ - es cualquier información que se relacione con un usuario identificado o identificable.
+- _Servicio_ - se refiere a este sitio web XRPL.org.
+- _Proveedor de servicios_ - significa cualquier persona normal o jurídica que procesa los datos en nombre de MTU XRP Ledger Trust. Se refiere a tercaras compañías o individuos contratados por MTU XRP Ledger Trust para facilitar el Servicio, para proveer el Servicio en nombre de MTU XRP Ledger Trust, para realizar servicios relacionados con el Servicio o para asistir a MTU XRP Ledger Trust analizando como el Servicio es utilizado.
+- _Datos de Uso_ - se refiere a datos recopilados automáticamente, generados por el uso del Servicio o la infraestructura del Servicio en sí (por ejemplo, la duración de una página visitada).
+- _Tú_ - significa el individuo que accede o usa el Servicio, o MTU XRP Ledger Trust, u otra entidad legal en nombre de la cual dicho individuo accede al Servicio, según corresponda.
## Recopilación y uso de tus datos
@@ -36,9 +37,9 @@ Nosotros también podemos recopilar información que Tu navegador envía cada ve
Nosotros utilizamos Cookies y tecnologías de seguimiento similares para rastrear la actividad en Nuestro Servicio y almacenar cierta información. Las tecnologías de seguimiento utilizadas son beacons, tags y scripts para recopilar y rastrear información y para mejorar y analizar Nuestro Servicio. Las tecnologías que utilizamos pueden incluir:
-* _Cookies o Cookies del Navegador_ - Una cookie es un pequeño archivo colocado en Tu Dispositivo. Puede instruir a Tu navegador para que rechace todas las Cookies o para que te indique cuándo se envía una Cookie. Sin embargo, si Tu no aceptas Cookies, es posible que no puedas utilizar algunas partes de nuestro Servicio. A menos que hayas ajustado Tu configuración del navegador para que rechace Cookies, nuestro Servicio puede utilizar Cookies.
-* _Cookies Flash_ - Ciertas funciones de nuestro Servicio pueden utilizar objetos almacenados localmente (o Cookies Flash) para recopilar y almacenar información sobre Tus preferencias o Tu actividad en nuestro Servicio. Las Cookies Flash no son administradas por la misma configuración del navegador que se utiliza para las Cookies del Navegador.
-* _Web Beacons_ - Ciertas secciones de nuestro Servicio pueden contener pequeños archivos electrónicos conocidos como web beacons (también denominadas clear gifs, pixel tags y gifs de píxeles únicos) que permiten a la Compañía, por ejemplo, contar usuarios que han visitado esas páginas o abierto un correo electrónico y para otras estadísticas relacionadas con el sitio web (por ejemplo, registrar la popularidad de una cierta sección y verificar la integridad del sistema y del servidor).
+- _Cookies o Cookies del Navegador_ - Una cookie es un pequeño archivo colocado en Tu Dispositivo. Puede instruir a Tu navegador para que rechace todas las Cookies o para que te indique cuándo se envía una Cookie. Sin embargo, si Tu no aceptas Cookies, es posible que no puedas utilizar algunas partes de nuestro Servicio. A menos que hayas ajustado Tu configuración del navegador para que rechace Cookies, nuestro Servicio puede utilizar Cookies.
+- _Cookies Flash_ - Ciertas funciones de nuestro Servicio pueden utilizar objetos almacenados localmente (o Cookies Flash) para recopilar y almacenar información sobre Tus preferencias o Tu actividad en nuestro Servicio. Las Cookies Flash no son administradas por la misma configuración del navegador que se utiliza para las Cookies del Navegador.
+- _Web Beacons_ - Ciertas secciones de nuestro Servicio pueden contener pequeños archivos electrónicos conocidos como web beacons (también denominadas clear gifs, pixel tags y gifs de píxeles únicos) que permiten a la Compañía, por ejemplo, contar usuarios que han visitado esas páginas o abierto un correo electrónico y para otras estadísticas relacionadas con el sitio web (por ejemplo, registrar la popularidad de una cierta sección y verificar la integridad del sistema y del servidor).
Las Cookies pueden ser "Persistentes" o de "Sesión". Las Cookies Persistentes permanecen en Tu computadora personal o dispositivo móvil cuando te desconectas, mientras que las Cookies de Sesión se eliminan tan pronto como cierras Tu navegador web.
@@ -79,11 +80,11 @@ Bajo ciertas circunstancias, La Compañía puede estar obligada a divulgar Tus D
La Compañía puede divulgar Tus Datos de Uso en creencia de buena fe de que dicha accion es necesaria para:
-* Cumplir con una obligación legal
-* Proteger y defender los derechos y propiedades de La Compañía
-* Prevenir o investigar posibles irregularidades en relación con el Servicio
-* Proteger la seguridad personal de los Usuarios del Servicio o del público
-* Protegerse contra la responsabilidad legal
+- Cumplir con una obligación legal
+- Proteger y defender los derechos y propiedades de La Compañía
+- Prevenir o investigar posibles irregularidades en relación con el Servicio
+- Proteger la seguridad personal de los Usuarios del Servicio o del público
+- Protegerse contra la responsabilidad legal
## Seguridad de Tus Datos Personales
diff --git a/@l10n/es-ES/community/report-a-scam.md b/@l10n/es-ES/community/report-a-scam.md
index 591741af29..cc9332d5d2 100644
--- a/@l10n/es-ES/community/report-a-scam.md
+++ b/@l10n/es-ES/community/report-a-scam.md
@@ -2,27 +2,28 @@
html: report-a-scam.html
parent: contribute.html
---
+
# Reportar una estafa
En una industria que evoluciona dónde la confianza y la seguridad son críticas, las estafas continuan impidiendo el progreso en cripto y blockchain. Individuos y equipos de la comunidad XRP Ledger, como el equipo de Xrplorer forensics, ayuda a mitigar a esos timadores ofreciendo herramientas gratuitas para reportar estafas.
## Tomar medidas
+
Si piensas que has sido estafado, asegúrate de recoleccionar toda la información que puedas sobre la estafa y el estafador tan pronto como sea posible. Revisa las opciones abajo de cómo tomar medidas.
**Atención:** Por favor, ten en cuenta que _nadie_ puede congelar cuentas o revertir transacciones en el XRP Ledger. Esto es debido al diseño descentralizado de la blockchain del XRP Ledger.
1. Envía la cartera del estafador al [equipo Xrplorer forensics](https://xrplorer.com/forensics/submit).
- Esto ayuda a marcar cuentas usadas en actividades ilicitas e las incluye en un monitoreo adicional, auto-trazable, y con advertencias a otros usuarios, carteras, y exchanges.
+ Esto ayuda a marcar cuentas usadas en actividades ilicitas e las incluye en un monitoreo adicional, auto-trazable, y con advertencias a otros usuarios, carteras, y exchanges.
2. Reporta tu caso a tu autoridad policial local. Si el estafador es arrestado, es posible que consigas tu dinero de vuelta.
3. Si el estafador envió tu XRP a un exchange, asegúrate de contactar con el equipo de soporte del exchange. El exchange puede congelar la cuenta del estafador en el exchange. Aquí hay enlaces de soporte a unos cuantos exchanges conocidos:
-
- - [Binance](https://www.binance.com/en/support)
- - [Coinbase](https://help.coinbase.com/)
- - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
- - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
+ - [Binance](https://www.binance.com/en/support)
+ - [Coinbase](https://help.coinbase.com/)
+ - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
+ - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
4. Si el estafador intercambió XRP por otro token en el XRP Ledger, contacta con el emisor del token. El emisor podría ser capaz [congelar la línea de confianza del estafador]((../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md) de prevenir que el estafador pueda enviar esos tokens a otras personas.
diff --git a/@l10n/es-ES/docs/concepts/accounts/account-types.md b/@l10n/es-ES/docs/concepts/accounts/account-types.md
index b71b6a2ee5..ee122ec9cd 100644
--- a/@l10n/es-ES/docs/concepts/accounts/account-types.md
+++ b/@l10n/es-ES/docs/concepts/accounts/account-types.md
@@ -2,21 +2,21 @@
html: account-types.html
parent: accounts.html
seo:
- description: Los negocios que envían transacciones en el XRP Ledger automáticamente, deben configurar direcciones separadas para diferentes propósitos para minimizar el riesgo.
+ description: Los negocios que envían transacciones en el XRP Ledger automáticamente, deben configurar direcciones separadas para diferentes propósitos para minimizar el riesgo.
labels:
- Tokens
- Seguridad
---
+
# Tipos de cuenta
{% partial file="/docs/_snippets/issuing-and-operational-addresses-intro.md" /%}
-
## Ciclo de vida de los fondos
Cuando un emisor de tokens sigue esta separacion de roles, los fondos tienden a fluir en direcciones específicas, como se muetra en el siguiente diagrama:
-[{% inline-svg file="/docs/img/issued-currency-funds-flow.svg" /%}](/docs/img/issued-currency-funds-flow.svg "Diagrama: Los fondos fluyen desde la dirección emisora hasta las direcciones de reserva, a direcciones operacionales, hacia las direcciones de clientes y socios, y finalmente de regreso a la dirección emisora.")
+[{% inline-svg file="/docs/img/issued-currency-funds-flow.svg" /%}](/docs/img/issued-currency-funds-flow.svg 'Diagrama: Los fondos fluyen desde la dirección emisora hasta las direcciones de reserva, a direcciones operacionales, hacia las direcciones de clientes y socios, y finalmente de regreso a la dirección emisora.')
La dirección emisora crea tokens enviando pagos a direcciones de reserva. Esos tokens tienen un valor negativo desde la perspectiva de la dirección emisora, ya que (a menudo) representan obligaciones. Los mismos tokens tienen valor positivo desde la otras perspectivas, incluyendo desde la perspectiva de las direcciones de reserva.
@@ -28,7 +28,6 @@ Como siempre, los pagos con tokens deben moverse a través de líneas de confian
Eventualmente, alguien envía tokens de vuelta al emisor. Esto destruye esos tokens, reduciendo las obligaciones del emisor con el XRP Ledger. Si el token es una stablecoin, esto es el primer paso para canjear los tokens por los activos correspondientes fuera del ledger.
-
## Dirección emisora
La dirección emisora es como una caja fuerte. Los socios, clientes y direcciones operacionales crean, líneas de confianza (trust lines) a la dirección emisora, pero esta dirección envía la menor cantidad de transacciones posibles. Periodícamente, un operador humano crea y firma una transacción desde la dirección emisora para recargar los balances de una dirección operacional o de reserva. Idealmente, la clave secreta utilizada para firmar esas transacciones nunca debería ser accesible desde ningun equipo conectado a Internet.
@@ -43,7 +42,6 @@ Si un actor malicioso descubre la clave secreta de la dirección emisora de una
Una institución financiera puede emitir más de un token en el XRP Ledger desde una única dirección de emisión. Sin embargo, hay algunas configuraciones que se aplican por igual a todos los tokens (fungibles) emitidos desde una dirección, incluido el porcentaje de [comisiones de transferencia](../tokens/fungible-tokens/transfer-fees.md) y el estado [congelación global](../tokens/fungible-tokens/freezes.md). Si la intitución financiera quiere la flexibilidad de manejar las configuraciones de distinta manera para cada token, la institución debe tener múltiples direcciones emisoras.
-
## Direcciones operacionales
Una dirección operacional es como una caja registradora. Realiza pagos en nombre de la institución para transferir tokens a clientes y socios. Para firmar transacciones automáticamente, la clave secreta para una dirección operacional debe ser alacenada en un servidor que está conectado a Internet. (La clave secreta puede estar almacenada encriptada, pero el servidor debe desencriptarla para firmar las transacciones.) Clientes y socios no crean ni deben crear trust lines a direcciones operacionales.
@@ -54,10 +52,9 @@ Cada dirección operacional tiene un balance limitado de tokens y XRP. Cuando el
Si un actor malicioso descubre la clave secreta detrás de una dirección operacional, la institución financiera sólo puede perder tanto como esa dirección operacional contiene. La institución puede cambiar a una nueva dirección operacional sin que los clientes y socios tengan que realizar ninguna acción.
-
## Direcciones de reserva
-Otro paso opcional que una institución puede equilibrar el riesgo y la convivencia es utilizada como "direcciones de reserva" como paso intermedio entre la dirección emisora y las direcciones operativas. La institución puede financiar direcciones XRP Ledger adicionales como direcciones de reserva, cuyas claves no están disponibles para los servidores siempre en línea, sino que confian a diferentes usuarios confiables.
+Otro paso opcional que una institución puede equilibrar el riesgo y la convivencia es utilizada como "direcciones de reserva" como paso intermedio entre la dirección emisora y las direcciones operativas. La institución puede financiar direcciones XRP Ledger adicionales como direcciones de reserva, cuyas claves no están disponibles para los servidores siempre en línea, sino que confian a diferentes usuarios confiables.
Cuando una dirección operacional se está quedando sin fondos (ya sea tokens o XRP), un usuario confiable pueed utilizar su dirección de reserva para recargar el balance de una dirección operacional. Cuando una dirección de reserva se queda sin fondos, la institución puede usar la dirección emisora para enviar más fondos a la dirección de reserva en una sola transacción, y la dirección de reserva puede distribuir esos fondos entre sí si es necesario. Esto mejora la seguridad de la dirección emisora, permitíendole hacer menos transacciones, sin dejar demasiado dinero en un único sistema automatizado.
@@ -67,18 +64,17 @@ Como con las direcciones operacionales, una direccion de reserva debe tener una
Si una dirección de reserva se ve comprometida, las consecuencias son similares a las de una dirección operacional. Un actor malintencionado puede robar cualquier saldo que posea la dirección de reserva, y la institución financiera puede cambiar a una nueva dirección de reserva sin que los clientes y socios realicen ninguna acción.
-
## Ver también
- **Conceptos:**
- - [Cuentas](index.md)
- - [Claves criptográficas](cryptographic-keys.md)
+ - [Cuentas](index.md)
+ - [Claves criptográficas](cryptographic-keys.md)
- **Tutoriales:**
- - [Asignar par de claves regulares](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
- - [Cambiar o eliminar par de claves regulares](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+ - [Asignar par de claves regulares](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+ - [Cambiar o eliminar par de claves regulares](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
- **Referencias:**
- - [metodo account_info][]
- - [Transacción SetRegularKey][]
- - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+ - [metodo account_info][]
+ - [Transacción SetRegularKey][]
+ - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/accounts/addresses.md b/@l10n/es-ES/docs/concepts/accounts/addresses.md
index 4237382846..82d664489d 100644
--- a/@l10n/es-ES/docs/concepts/accounts/addresses.md
+++ b/@l10n/es-ES/docs/concepts/accounts/addresses.md
@@ -2,10 +2,11 @@
html: addresses.html
parent: accounts.html
seo:
- description: Las direcciones identifican de manera única las cuentas del XRP Ledger, utilizando el formato base58.
+ description: Las direcciones identifican de manera única las cuentas del XRP Ledger, utilizando el formato base58.
labels:
- Cuentas
---
+
# Direcciones
{% partial file="/docs/_snippets/data_types/address.md" /%}
@@ -14,20 +15,17 @@ Cualquier dirección válida puede [convertirse en una cuenta en el XRP Ledger](
Crear una dirección válida es una tarea estríctamente matemática que empieza con el par de claves. Puedes generar un par de claves y calcular su dirección completamente offline sin comunicarte con el XRP Ledger o con cualquier otra entidad. La conversión desde una clave pública a una dirección implica una función hash unidireccional, por lo que es posible confirmar que esa clave pública coincide con una dirección pero es imposible derivar la clave pública únicamente a partir de la dirección. (Esta es parte de la razón por la que las transacciones firmadas incluyen la clave pública _y_ la dirección del remitente.)
-
## Direcciones especiales
Algunas direcciones tienen un significado especial, o usos históricos, en el XRP Ledger. En muchos casos, se tratan de direcciones "black hole" o agujero negro, lo que significa que la dirección no se deriva de una clave secreta conocida. Como es efectivamente imposible adivinar una clave secreta a partir de una sola dirección, cualquier XRP que posean direcciones black hole estarán perdidos para siempre.
-
-| Dirección | Nombre | Significado | ¿Black Hole? |
-|-------------------------------|--------|-------------|--------------|
-| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `0`. En comunicaciones peer-to-peer, `rippled` utiliza esta dirección como el emisor de XRP. | Sí |
-| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `1`. En el ledger, las [entradas RippleState](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) utilizan esta dirección como marcador de posición para el emisor de un balance de una trust line. | Sí |
-| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | La cuenta génesis | Cuando `rippled` inicia un nuevo ledger génesis desde el principio (por ejemplo, en modo solitario), esta cuenta contiene todo el XRP. Esta cuenta es generada con el valor semilla `masterpassphrase` el cual está [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
-| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | black hole de reserva de nombre de Ripple | En el pasado, Ripple pedía a los usuarios enviar XRP a esta cuenta para reservar nombres Ripple.| Sí |
-| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | Dirección NaN | Versiones previas de [ripple-lib](https://github.com/XRPLF/xrpl.js) generaban esta dirección cuando se codificaba el valor [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) utilizan el formato de codificación [base58][] del XRP Ledger. | Sí |
-
+| Dirección | Nombre | Significado | ¿Black Hole? |
+| ------------------------------------ | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
+| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT_ZERO | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `0`. En comunicaciones peer-to-peer, `rippled` utiliza esta dirección como el emisor de XRP. | Sí |
+| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT_ONE | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `1`. En el ledger, las [entradas RippleState](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) utilizan esta dirección como marcador de posición para el emisor de un balance de una trust line. | Sí |
+| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | La cuenta génesis | Cuando `rippled` inicia un nuevo ledger génesis desde el principio (por ejemplo, en modo solitario), esta cuenta contiene todo el XRP. Esta cuenta es generada con el valor semilla `masterpassphrase` el cual está [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
+| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | black hole de reserva de nombre de Ripple | En el pasado, Ripple pedía a los usuarios enviar XRP a esta cuenta para reservar nombres Ripple. | Sí |
+| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | Dirección NaN | Versiones previas de [ripple-lib](https://github.com/XRPLF/xrpl.js) generaban esta dirección cuando se codificaba el valor [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) utilizan el formato de codificación [base58][] del XRP Ledger. | Sí |
## Codificación de una dirección
@@ -39,11 +37,11 @@ Las direcciones XRP Ledger están codificadas utilizando [base58][] con el _dicc
El siguiente diagrama muestra la relación entre las claves y las direcciones:
-[{% inline-svg file="/docs/img/address-encoding.svg" /%}](/docs/img/address-encoding.svg "Clave pública maestra + Prefijo Tipo → ID de cuenta + Checksum → Dirección")
+[{% inline-svg file="/docs/img/address-encoding.svg" /%}](/docs/img/address-encoding.svg 'Clave pública maestra + Prefijo Tipo → ID de cuenta + Checksum → Dirección')
La fórmula para calcular direcciones XRP Ledger desde una clave pública es la siguiente. Para ver el código de ejemplo completo, consulta [`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js). Para el proceso de derivar la clave pública desde una passphrase a un valor semilla, consulta [Derivación de clave](cryptographic-keys.md#key-derivation).
-1. Importa los algoritmos necesarios: SHA-256, RIPEMD160, y base58. Configura el diccionario para base58.
+1. Importa los algoritmos necesarios: SHA-256, RIPEMD160, y base58. Configura el diccionario para base58.
```
'use strict';
@@ -56,7 +54,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
assert(crypto.getHashes().includes('ripemd160'));
```
-2. Empieza con una clave pública 33-byte ECDSA secp256k1, o una clave pública 32-byte Ed25519. Para claves Ed25519, prefija la clave con el byte `0xED`.
+2. Empieza con una clave pública 33-byte ECDSA secp256k1, o una clave pública 32-byte Ed25519. Para claves Ed25519, prefija la clave con el byte `0xED`.
```
const pubkey_hex =
@@ -65,7 +63,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
assert(pubkey.length == 33);
```
-3. Calcula el hash [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) del hash SHA-256 de la clave pùblica. Este valor es el ID de cuenta o "Account ID".
+3. Calcula el hash [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) del hash SHA-256 de la clave pùblica. Este valor es el ID de cuenta o "Account ID".
```
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
@@ -74,7 +72,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
const account_id = pubkey_outer_hash.digest();
```
-4. Calcula el hash SHA-256 hash del hash SHA-256 del Account ID; toma los 4 primeros bytes. Este valor es el "checksum".
+4. Calcula el hash SHA-256 hash del hash SHA-256 del Account ID; toma los 4 primeros bytes. Este valor es el "checksum".
```
const address_type_prefix = Buffer.from([0x00]);
@@ -84,7 +82,7 @@ La fórmula para calcular direcciones XRP Ledger desde una clave pública es la
const checksum = chksum_hash2.slice(0,4);
```
-5. Concatena el payload y el checksum. Calcula el valor base58 del buffer concatenado. El resultado es la dirección.
+5. Concatena el payload y el checksum. Calcula el valor base58 del buffer concatenado. El resultado es la dirección.
```
const dataToEncode = Buffer.concat([payload, checksum]);
diff --git a/@l10n/es-ES/docs/concepts/accounts/cryptographic-keys.md b/@l10n/es-ES/docs/concepts/accounts/cryptographic-keys.md
index 1fff285868..0f98da73d8 100644
--- a/@l10n/es-ES/docs/concepts/accounts/cryptographic-keys.md
+++ b/@l10n/es-ES/docs/concepts/accounts/cryptographic-keys.md
@@ -2,11 +2,12 @@
html: cryptographic-keys.html
parent: accounts.html
seo:
- description: Utiliza las claves criptográficas para aprobar transacciones para que el XRP Ledger pueda ejecutarlas.
+ description: Utiliza las claves criptográficas para aprobar transacciones para que el XRP Ledger pueda ejecutarlas.
labels:
- Smart Contracts
- Seguridad
---
+
# Claves criptográficas
En el XRP Ledger, una firma digital _autoriza_ a una [transacción](../transactions/index.md) a hacer un grupo específico de acciones. Solo las transacciones firmadas pueden ser enviadas a la red y ser incluidas en un ledger validado.
@@ -19,14 +20,13 @@ Para realizar una firma digital, utilizas un par de claves criptográficas asoci
Muchas [librerías de cliente](../../references/client-libraries.md) y aplicaciones pueden generar un par de claves adecuadas para usar con el XRP Ledger. Sin embargo, solo deberías utilizar los pares de claves que fueron generados en dispositivos y software en los que confías. Las aplicaciones comprometidas pueden exponer tu secreto a usuarios maliciosos que pueden enviar transacciones desde tu cuenta luego.
-
## Componentes de clave
Un par de claves criptográficas es una **clave privada** y una **clave pública** que están conectadas matemáticamente a través de un proceso de derivación de claves. Cada clave es un número; la clave privada debería elegirse usando una fuente de aleatoriedad fuerte. El [algoritmo de firma criptográfica](#algoritmos-de-firma) define el proceso de derivación de claves y establece restricciones en los números que pueden ser claves criptográficas.
Al tratar con el XRP Ledger, también puedes utilizar algunos valores relacionados como passphrase, semilla, ID de cuenta, y dirección.
-[{% inline-svg file="/docs/img/cryptographic-keys.svg" /%}](/docs/img/cryptographic-keys.svg "Diagrama: Passphrase → Semilla → Clave privada → Clave pública → ID de cuenta ←→ Dirección")
+[{% inline-svg file="/docs/img/cryptographic-keys.svg" /%}](/docs/img/cryptographic-keys.svg 'Diagrama: Passphrase → Semilla → Clave privada → Clave pública → ID de cuenta ←→ Dirección')
_Figura: Una vista simplificada de la relación entre los valores de clave criptográfica._
La passphrase, semilla, y la clave privada son **secretos**: si conoces alguno de estos valores para una cuenta, puedes generar firmas válidas y tienes el control total sobre la cuenta. Si tienes una cuenta, se **muy cuidadoso** con la información secreta de tu cuenta. Si no tienes estos secretos, no puedes usar tu cuenta. Si alguien más tiene acceso a ellos, puede tener el control de tu cuenta.
@@ -37,11 +37,11 @@ Para más detalles técnicos y como la derivación de clave funciona, ver [Deriv
### Passphrase
-Puedes, opcionalmente, usar una passphrase u algún otro valor de entrada como forma de elegir una semilla o una clave privada. Esto es menos seguro que elegir la semilla o la clave privada desde la aleatoriedad, pero hay algunos casos excepcionales dónde quieras hacer esto. (Por ejemplo, en 2018 "XRPuzzler" regaló XRP a la primera persona [en resolver un puzzle](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/); él utilizó la solución del puzzle como la passphrase para la cuenta que tenía el premio en XRP.)
+Puedes, opcionalmente, usar una passphrase u algún otro valor de entrada como forma de elegir una semilla o una clave privada. Esto es menos seguro que elegir la semilla o la clave privada desde la aleatoriedad, pero hay algunos casos excepcionales dónde quieras hacer esto. (Por ejemplo, en 2018 "XRPuzzler" regaló XRP a la primera persona [en resolver un puzzle](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/); él utilizó la solución del puzzle como la passphrase para la cuenta que tenía el premio en XRP.)
La passphrase es información secreta, por lo que debes protegerla con mucho cuidado. Cualquiera que conozca la passphrase de la dirección tiene control total efectivo sobre la cuenta.
-### Semilla
+### Semilla
Un valor _semilla_ es un valor compacto que se utiliza para [derivar](#derivación-de-claves) las claves privada y pública actual de una cuenta. En la respuesta de un [método wallet_propose][], las `master_key`, `master_seed`, y `master_seed_hex` todas representan el mismo valor semilla, en varios formatos. Cualquiera de esos formatos puede ser utilizado para firmar transacciones. A pesar de tener el prefijo `master_`, las claves que esta semilla representa no necesariamente representan las claves maestras de una cuenta; puedes usar un par de claves como una clave normal o un miembro de una lista de firmantes.
@@ -59,10 +59,9 @@ La _clave pública_ es un valor utilizado para verificar la autenticidad de una
Las transacciones en el XRP Ledger deben incluir las claves públicas para que la red pueda verificar las firmas de las transacciones. La clave pública no se puede utilizar para crear firmas válidas, así que es seguro compartirla públicamente.
-
### ID de cuenta y dirección
-El **ID de cuenta** es el identificador principal para una [cuenta](index.md) o para un par de claves. Se deriva de la clave pública. En el protocolo XRP Ledger, el ID de cuenta es un dato binario de 20 bytes. La mayoría de las APIs XRP Ledger representan la Account ID como una dirección, en uno de dos formatos:
+El **ID de cuenta** es el identificador principal para una [cuenta](index.md) o para un par de claves. Se deriva de la clave pública. En el protocolo XRP Ledger, el ID de cuenta es un dato binario de 20 bytes. La mayoría de las APIs XRP Ledger representan la Account ID como una dirección, en uno de dos formatos:
- Una "dirección clásica" escribe una ID de cuenta en [base58][] con un checksum. En una respuesta del [método wallet_propose][], este es el valor `account_id`.
- Una "dirección-X" combina una ID de cuenta _y_ un [Tag de destino](../transactions/source-and-destination-tags.md) y escribe el valor combinado en [base58][] con un checksum.
@@ -79,7 +78,6 @@ El XRP Ledger soporta más de un [algoritmo de firma criptográfica](#algoritmos
El campo `key_type` en el [método wallet_propose][] se refiere al algoritmo de firma criptográfica que se utilizará.
-
## Par de claves maestras
El par de claves maestras consiste en una clave privada y una clave publica. La dirección de una cuenta es derivada del par de claves maestras, por lo que están intrinsecamente relacionadas. No puedes cambiar o eliminar el par de claves maestras, pero puedes desactivarlo.
@@ -92,8 +90,6 @@ Dado que cambiar el par de claves maestras es imposible, debes cuidarlo en propo
Mantener tu par de claves maestras offline significa no colocar tu información secreta (passphrase, semilla, or clave privada) en cualquier sitio en que los actores maliciosos puedan tener acceso a él. En general, esto quiere decir que no está al alcance de un programa inofrmático que interactúe con Internet. Por ejemplo, puedes guardarlo en un equipo que no se conecta nunca a Internet, en un trozo de papel guardado en una caja fuerte, o tenerla completamente memorizada. (Memorizarla tiene algunos puntos inconvenientes, incluido ser imposible pasar la clave una vez muerto.)
-
-
### Permisos especiales
**Solo** el par de claves maestras pueden autorizar transacciones para hacer ciertas cosas:
@@ -108,7 +104,6 @@ Mantener tu par de claves maestras offline significa no colocar tu información
Una clave normal o [multi-firma](multi-signing.md) puede hacer cualquier otra cosa igual que el par de claves maestras. En particular, una vez has deshabilitado el par de claves maestras, puedes volver a habilitarlo utilizando un par de claves normales o multi firma. También puedes [eliminar una cuenta](deleting-accounts.md) si cumple con los requisitos para su eliminación.
-
## Par de claves normales
Una cuenta XRP Ledger puede autorizar un par de claves secundario, conocido como _par de claves normales_. Tras hacerlo, puedes utilizar cualquiera, el [par de claves maestras](#par-de-claves-maestras) o el par de claves normales para autorizar transacciones. Puedes eliminar o reemplazar tu par de claves normales en cualquier momento sin cambiar el resto de la cuenta.
@@ -121,28 +116,25 @@ El par de claves normales tiene el mismo formato que el par de claves maestras.
La [transacción SetRegularKey][] asigna o cambia el par de claves normales de una cuenta. Para un tutorial de asignación o cambio de un par de claves normales, ver [Asignar par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md).
-
## Algorítmos de firma
Los pares de claves criptográficas están siempre atadas a un algorítmo de firma específico, el cual define la relación matemática entre la clave secreta y la clave pública. Los algorítmos de firma criptográficos tienen la propiedad de, dado el estado actual de las técnicas de criptografía, es "fácil" utilizar una clave secreta para clacular la clave pública coincidente, pero es imposible calcular la clave secreta vinculante partiendo de la clave pública.
El XRP Ledger soporta los siguientes algoritmos de firma criptográfica:
-| Tipo de clave | Algoritmo | Descripción |
-|-------------|-----------|---|
-| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) usando la curva eliptica [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | Este es el mismo esquema que utiliza Bitcoin. El XRP Ledger utiliza este tipo de claves por defecto. |
-| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) usando la curva elíptica [Ed25519](https://ed25519.cr.yp.to/) | Este es un algoritmo más novedoso que tiene mejor rendimiento y otras propiedades convenientes. Como las claves públicas Ed25519 son un byte menos que las claves secp256k1, `rippled` prefija las claves públicas Ed25519 con el byte `0xED` así ambos tipos de claves públicas son de 33 bytes. |
+| Tipo de clave | Algoritmo | Descripción |
+| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) usando la curva eliptica [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | Este es el mismo esquema que utiliza Bitcoin. El XRP Ledger utiliza este tipo de claves por defecto. |
+| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) usando la curva elíptica [Ed25519](https://ed25519.cr.yp.to/) | Este es un algoritmo más novedoso que tiene mejor rendimiento y otras propiedades convenientes. Como las claves públicas Ed25519 son un byte menos que las claves secp256k1, `rippled` prefija las claves públicas Ed25519 con el byte `0xED` así ambos tipos de claves públicas son de 33 bytes. |
Cuando generas un par de claves con el [método wallet_propose][], puedes especificar el `key_type` para elegir que tipo de algorítmo criptográfico se utiliza para derivar las claves. Si has generado un tipo de clave disitnto al de por defecto, debes especificar también el `key_type` cuando firmas transacciones.
-Los tipos de pares de claves admitidos pueden utilizarse indistintatemente en todo el XRP Ledger como pares de claves maestras, pares de claves normales, y miembros de listas de firmantes. El proceso de [derivación de una dirección](addresses.md#address-encoding) es el mismo para pares de claves secp256k1 y Ed25519.
-
+Los tipos de pares de claves admitidos pueden utilizarse indistintatemente en todo el XRP Ledger como pares de claves maestras, pares de claves normales, y miembros de listas de firmantes. El proceso de [derivación de una dirección](addresses.md#address-encoding) es el mismo para pares de claves secp256k1 y Ed25519.
### Algoritmos futuros
En el futuro, es posible que el XRP Ledger necesite nuevos algoritmos de firma criptográficos para mantenerse al día con el desarrollo en criptográfia. Por ejemplo, si los ordenadores cuánticos utilizasen el [algoritmo de Shor](https://en.wikipedia.org/wiki/Shor's_algorithm) (o algo similar) no tardarán en romper la curva elíptica criptográfica, los desarrolladores XRP Ledger pueden añadir un algoritmo criptográfico que no es facil de romper. A mediados de 2020, no existe un algoritmo de firma "resistente a la cuántica" y los ordenadores cuánticos no son lo suficientemente prácticos para ser una amenaza, por lo que no hay planes inmediatos para añadir algoritmos específicos.
-
## Derivación de claves
El proceso de derivar un par de claves depende del algoritmo de firma. En todos los casos, las claves son generadas desde un valor _seed_ (semilla) que es de 16 bytes (128 bits) de longitud. El valor semilla puede ser totalmente aleatorio (recomendado) o puede ser derivado de una passphrase específica tomando el [hash SHA-512][Hash] y manteniendo los primeros 16 bytes (como [SHA-512Half][], pero manteniendo solo 128 bits en vez de los 256 bits de la salida).
@@ -152,37 +144,39 @@ El proceso de derivar un par de claves depende del algoritmo de firma. En todos
Los procesos de derivación de claves descritos aquí están implementados en múltiples lugares y lenguajes de programación:
- En C++ en el código base de `rippled`:
- - [Definición de semilla](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
- - [Derivación de clave general & Ed25519](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
- - [Derivación de clave secp256k1](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+ - [Definición de semilla](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
+ - [Derivación de clave general & Ed25519](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+ - [Derivación de clave secp256k1](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
- En Python 3 en {% repo-link path="_code-samples/key-derivation/py/key_derivation.py" %}esta sección de códigos de ejemplo del repositorio{% /repo-link %}.
- En JavaScript en el paquete [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs).
### Derivación de clave Ed25519
+
[[Fuente]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Fuente")
-[{% inline-svg file="/docs/img/key-derivation-ed25519.svg" /%}](/docs/img/key-derivation-ed25519.svg "Passphrase → Semilla → Clave secreta → Prefijo + Clave pública")
+[{% inline-svg file="/docs/img/key-derivation-ed25519.svg" /%}](/docs/img/key-derivation-ed25519.svg 'Passphrase → Semilla → Clave secreta → Prefijo + Clave pública')
1. Calcular el [SHA-512Half][] del valor de la semilla. El resultado es la clave secreta de 32-byte.
- **Consejo:** Todos los números 32-byte son válidos como claves secretas Ed25519. Sin embargo, Sin embargo, solo los números elegidos aleatoriamente son suficientemente seguros para ser usados como claves secretas.
+ **Consejo:** Todos los números 32-byte son válidos como claves secretas Ed25519. Sin embargo, Sin embargo, solo los números elegidos aleatoriamente son suficientemente seguros para ser usados como claves secretas.
2. Para calcular una clave pública Ed25519, utiliza la derivación estandar de clave pública para [Ed25519](https://ed25519.cr.yp.to/software.html) para derivar una clave pública de 32-byte.
- **Atención:** Como con cualquier algoritmo criptográfico, utiliza una implementación estandar, reconocida y públicamente auditada cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales para Ed25519 y secp256k1.
+ **Atención:** Como con cualquier algoritmo criptográfico, utiliza una implementación estandar, reconocida y públicamente auditada cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales para Ed25519 y secp256k1.
3. Prefija el byte `0xED` en la clave pública 32-byte para indicar que es una clave pública Ed25519, resultando en 33 bytes.
- Si estás impementando código para firmar transacciones, elimina el prefijo `0xED` y utiliza la clave 32-byte para el proceso de firma actual.
+ Si estás impementando código para firmar transacciones, elimina el prefijo `0xED` y utiliza la clave 32-byte para el proceso de firma actual.
4. Cuando serializas una clave pública de cuenta a [base58][], utiliza el prefijo de la clave pública de cuenta `0x23`.
- Las claves efímeras de validador no pueden ser Ed25519.
+ Las claves efímeras de validador no pueden ser Ed25519.
### Derivación de clave secp256k1
+
[[Fuente]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Fuente")
-[{% inline-svg file="/docs/img/key-derivation-secp256k1.svg" /%}](/docs/img/key-derivation-secp256k1.svg "Passphrase → Semilla → Par de claves inicial (Root Key Pair) → Par de claves intermedias → Par de claves maestras")
+[{% inline-svg file="/docs/img/key-derivation-secp256k1.svg" /%}](/docs/img/key-derivation-secp256k1.svg 'Passphrase → Semilla → Par de claves inicial (Root Key Pair) → Par de claves intermedias → Par de claves maestras')
La derivación de claves de cuentas XRP Ledger secp256k1 involucra más pasos que con la derivación de clave Ed25519 por el siguiente par de razones:
@@ -191,23 +185,22 @@ La derivación de claves de cuentas XRP Ledger secp256k1 involucra más pasos qu
Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un valor semilla es como sigue:
-1. Calcular un par de claves iniciales (root key pair) a partir del valor semilla, como sigue:
-
+1. Calcular un par de claves iniciales (root key pair) a partir del valor semilla, como sigue:
1. Concatenar lo siguiente en orden, para un total de 20 bytes:
- - El valor semilla (16 bytes)
- - El valor "sequencia root" (4 bytes), como un entero big-endian no asignado. Utiliza 0 como un valor inicial para la secuencia root.
+ - El valor semilla (16 bytes)
+ - El valor "sequencia root" (4 bytes), como un entero big-endian no asignado. Utiliza 0 como un valor inicial para la secuencia root.
2. Calcular el [SHA-512Half][] del valor concatenado ( semilla+secuencia root).
3. Si el resultado no es una clave secreta válida secp256k1, incrementa la secuencia root en 1 y vuelve a empezar. [[Fuente]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Fuente")
- Una clave válida secp256k1 debe no ser cero, y debe ser numericamente menor que _secp256k1 group order_. El orden grupo secp256k1 es un valor constante `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.
+ Una clave válida secp256k1 debe no ser cero, y debe ser numericamente menor que _secp256k1 group order_. El orden grupo secp256k1 es un valor constante `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.
4. Con una clave secreta secp256k1 válida, utiliza la derivación de clave pública ECDSA estandar con la curva secp256k1 para derivar la clave pública inicial (root). (Como siempre para algoritmos critográficos, utiliza una implementación auditada públicamente, conocida y estandar cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones para funciones principales de Ed25519 y secp256k1.)
**Consejo:** Los validadores utilizan este par de claves iniciales (root). Si estás calculando un par de claves para un validador, puedes parar aquí. Para disntiguir entre estos dos tipos de claves públicas, la serialización para claves públicas de validador [base58][] usa el prefijo `0x1c`.
-2. Convierte la clave pública inicial (root) a su forma comprimida de 33-byte.
+2. Convierte la clave pública inicial (root) a su forma comprimida de 33-byte.
La forma no comprimida de cualquier clave pública ECDSA consiste en un par de enteros de 32-byte: una coordinada X, y una coordinada Y. La forma comprimida es la coordinada X y un prefijo de one-byte: `0x02` si la coordinada Y es par, o `0x03` si la coordinada Y es impar.
@@ -217,12 +210,11 @@ Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un val
$ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
```
-3. Deriva un "par de claves intermedio" desde la clave pública ráiz comprimida, así:
-
+3. Deriva un "par de claves intermedio" desde la clave pública ráiz comprimida, así:
1. Concatena lo siguiente en orden, para un total de 41 bytes:
- - La clave pública comprimida (33 bytes)
- - `0x00000000000000000000000000000000` (4 bytes de ceros). (Este valor estaba pensado para derivar diferentes números de la misma familia, pero en la práctica solo el valor 0 es utilizado.)
- - Una valor "secuencia clave" (4 bytes), como un entero no asignado big-endian. Utiliza 0 como valor inicial para la secuencia clave.
+ - La clave pública comprimida (33 bytes)
+ - `0x00000000000000000000000000000000` (4 bytes de ceros). (Este valor estaba pensado para derivar diferentes números de la misma familia, pero en la práctica solo el valor 0 es utilizado.)
+ - Una valor "secuencia clave" (4 bytes), como un entero no asignado big-endian. Utiliza 0 como valor inicial para la secuencia clave.
2. Calcula el [SHA-512Half][] del valor concatenado.
@@ -230,30 +222,28 @@ Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un val
4. Con una clave secreta secp256k1 válida, utiliza la derivación de clave pública ECDSA estandar con la curva secp256k1 para derivar la clave pública intermedia. (Como siempre con los algoritmos criptográficos, utiliza una implementación públicamente auditada, conocida y estandar cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales Ed25519 y secp256k1.)
-4. Deriva el par de claves públicas añadiendo la clave pública intermedia a la clave pública inicial (root). De manera similar, deriva la clave secreta añadiendo la clave secreta intermedia a la clave secreta inicial (root).
-
+4. Deriva el par de claves públicas añadiendo la clave pública intermedia a la clave pública inicial (root). De manera similar, deriva la clave secreta añadiendo la clave secreta intermedia a la clave secreta inicial (root).
- Una clave secreta ECDSA es un número entero muy largo, por lo que puedes calcular la suma de dos números secretos sumando el módulo el orden de grupo secp256k1.
- Una clave pública ECDSA es un punto de la curva elíptica, por lo que necesitarás matemática de curva elíptica para sumar los puntos.
-5. Convierte la clave pública maestra asu forma comprimida de 33-byte, como antes.
+5. Convierte la clave pública maestra asu forma comprimida de 33-byte, como antes.
-6. Cuando serialices la clave pública de la cuenta a su formato [base58][], utiliza el prefijo de la clave pública de la cuenta, `0x23`.
+6. Cuando serialices la clave pública de la cuenta a su formato [base58][], utiliza el prefijo de la clave pública de la cuenta, `0x23`.
Ver [Codificación de dirección](addresses.md#address-encoding) para información y códigos de ejemplo para convertir de una clave pública de cuenta a su dirección.
-
## Ver también
- **Conceptos:**
- - [Direcciones de emisión y operacionales](account-types.md)
+ - [Direcciones de emisión y operacionales](account-types.md)
- **Tutoriales:**
- - [Asignación de par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
- - [Cambiar o eliminar par de claves normales](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+ - [Asignación de par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+ - [Cambiar o eliminar par de claves normales](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
- **Referencias:**
- - [Transacción SetRegularKey][]
- - [Objeto de ledger AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
- - [método wallet_propose][]
- - [método account_info][]
+ - [Transacción SetRegularKey][]
+ - [Objeto de ledger AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+ - [método wallet_propose][]
+ - [método account_info][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md b/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md
index 1b78f341d4..fd4ca872d4 100644
--- a/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md
+++ b/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md
@@ -2,10 +2,11 @@
html: decentralized-identifiers.html
parent: accounts.html
seo:
- description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
+ description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
labels:
- DID
---
+
# Identificadores descentralizados
_(REquiere de la [enmienda DID][] {% not-enabled /%})_
@@ -22,18 +23,16 @@ Los principios clave de un DID son:
**Nota:** La implementación de DIDs en el XRP Ledger cumple con los requisitos de la [especificación DID v1.0](https://www.w3.org/TR/did-core/).
-
## Cómo funciona
1. El dueño de una cuenta XRPL genera un DID que es controlado por la cuenta.
2. El DID se asocia a un documento DID definido por la especificaciones W3C.
3. El DID es usado para las siguientes tareas digitales como:
- - Firmar documentos digitales.
- - Realizar transacciones en linea seguras.
- - Iniciar sesión en sitios web.
+ - Firmar documentos digitales.
+ - Realizar transacciones en linea seguras.
+ - Iniciar sesión en sitios web.
4. El verificador resuelve el DID a su docuemnto para verificar la identidad del sujeto.
-
## Documentos DID
Los documentos DID contienen la información necesaria para verificar criptográficamente la identidad del sujeto descrito por el documento DID. El sujeto puede ser una persona, organización, o cosa. Por ejemplo, un documento DID podría contener claves criptográficas públicas que el sujeto DID puede utilizar para autenticarse y demostrar su asociación con el DID.
@@ -44,31 +43,29 @@ En el XRP Ledger, hay numerosas formas de asociar un DID a un documento DID:
1. Almacenar una referencia al documento en el campo `URI` del objeto `DID`, que apunta al documento almacenado en otra red de almacenamiento descentralizado, como es IPFS o STORJ.
2. Almacenar un documento DID mínimo en el campo `DIDDocument` del objeto `DID`.
-3. Utilizar un documento DID _implicito_ generado a partir del DID y otra información pública disponible.
- **Nota:** Los casos de uso más simples pueden solo necesitar firmas y rokens de autorización simples. En casos donde no haya un documento DID explicitamente en el ledger, un documento implicito es utilizado en su lugar. Por ejemplo, el documento DID de `did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` habilita solo la clave única `0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` para autorizar cambios en el documento DID o firmar credenciales en nombre del DID.
-
+3. Utilizar un documento DID _implicito_ generado a partir del DID y otra información pública disponible.
+ **Nota:** Los casos de uso más simples pueden solo necesitar firmas y rokens de autorización simples. En casos donde no haya un documento DID explicitamente en el ledger, un documento implicito es utilizado en su lugar. Por ejemplo, el documento DID de `did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` habilita solo la clave única `0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` para autorizar cambios en el documento DID o firmar credenciales en nombre del DID.
### Ejemplo de documento DID XRPL
```json
{
- "@context": "https://w3id.org/did/v1",
- "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
- "publicKey": [
- {
- "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
- "type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
- "curve": "secp256k1",
- "expires": 15674657,
- "publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
- }
- ]
+ "@context": "https://w3id.org/did/v1",
+ "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+ "publicKey": [
+ {
+ "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
+ "type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
+ "curve": "secp256k1",
+ "expires": 15674657,
+ "publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
+ }
+ ]
}
```
Para aprender más sobre las propiedades principales de un documento DID, ver: [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/#core-properties).
-
## Precauciones de privacidad y seguridad
- Quien controla las claves privadas de la cuenta XRPL, controla el DID y las referencias al documento DID a la que resuelve. Asegúrate de que tus claves privadas no se comprometan.
diff --git a/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md b/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
index 50066fc8e4..945d314008 100644
--- a/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
+++ b/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
@@ -1,9 +1,10 @@
---
seo:
- description: Acerca de eliminar una cuenta XRP Ledger.
+ description: Acerca de eliminar una cuenta XRP Ledger.
labels:
- Cuentas
---
+
# Eliminar Cuentas
El dueño de una cuenta puede enviar una [transacción AccountDelete][] para eliminar la cuenta y las entradas relativas del ledger, enviando la mayoría del XRP en balance restante a otra cuenta. Para evitar la creación y eliminación de cuentas sin sentido, eliminar una cuenta requiere quemar una cantidad superior a la usual utilizada como [coste de transacción](../transactions/transaction-cost.md).
@@ -18,10 +19,10 @@ Para ser eliminada, una cuenta debe cumplir los siguientes requisitos:
- El número de `Sequence` de la cuenta más 256 debe ser menor que el [Índice del ledger][] actual.
- La cuenta no debe estar enlazada a de los siguientes tipos de [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md) (como remitente o destinatario):
- - `Escrow`
- - `PayChannel`
- - `RippleState`
- - `Check`
+ - `Escrow`
+ - `PayChannel`
+ - `RippleState`
+ - `Check`
- La cuenta debe tener menos de 1000 objetos en el ledger.
- La transacción debe pagar un [coste de transacción][] especial igual al menos a la [reserva de propietario](reserves.md) de un artículo (actualmente {% $env.PUBLIC_OWNER_RESERVE %}).
@@ -34,4 +35,5 @@ A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la
Instituciones que reciben y envían valor en nombre de muchos usuarios pueden utilizar [**Source Tags** y **Destination Tags**](../transactions/source-and-destination-tags.md) para distinguir pagos desde y para sus clientes usando una (o un puñado) de cuentas en el XRP Ledger.
+
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/accounts/depositauth.md b/@l10n/es-ES/docs/concepts/accounts/depositauth.md
index c8c2f5c335..9e7f36f8c0 100644
--- a/@l10n/es-ES/docs/concepts/accounts/depositauth.md
+++ b/@l10n/es-ES/docs/concepts/accounts/depositauth.md
@@ -2,11 +2,12 @@
html: depositauth.html
parent: accounts.html
seo:
- description: La configuración DepositAuth le permite a una cuenta bloquear pagos entrantes por defecto.
+ description: La configuración DepositAuth le permite a una cuenta bloquear pagos entrantes por defecto.
labels:
- Pagos
- Seguridad
---
+
# Autorización para depositar
_(Añadido por la [enmienda DepositAuth][].)_
@@ -41,29 +42,27 @@ Para conseguir un efecto total de Deposit Authorization, Ripple recomienda adem
Una cuenta con Deposit Authorization activado:
- **No puede** ser destinatario de [transacciones Payment][], con **las siguientes excepciones**:
- - Si el destinatario tiene [preautorizado](#preautorización) al remitente del pago. _(Añadido con la [enmienda DepositPreauth][])_
- - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente {% $env.PUBLIC_BASE_RESERVE %}). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
+ - Si el destinatario tiene [preautorizado](#preautorización) al remitente del pago. _(Añadido con la [enmienda DepositPreauth][])_
+ - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente {% $env.PUBLIC_BASE_RESERVE %}). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
- Puede recibir XRP de [transacciones PaymentChannelClaim][] **únicamente en los siguientes casos**:
- - El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
- - El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_
+ - El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
+ - El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_
- Puede recibir XRP de [transacciones EscrowFinish][] **únicamente en los siguientes casos**:
- - El remitente de una transacción EscrowFinish es el destino de un escrow.
- - El destino de una transacción EscrowFinish tiene [preautorizado](#preautorización) al remitente de un EscrowFinish. _(Añadido en la [enmienda DepositPreauth][])_
+ - El remitente de una transacción EscrowFinish es el destino de un escrow.
+ - El destino de una transacción EscrowFinish tiene [preautorizado](#preautorización) al remitente de un EscrowFinish. _(Añadido en la [enmienda DepositPreauth][])_
- **Puede** recibir XRP o tokens enviando una transacción [CheckCash][]. _(Añadido por la [enmienda Checks][].)_
- **Puede** recibir XRP o tokens enviando [transacciones OfferCreate][].
- - Si la cuenta envía una transacción OfferCreate que no está completamente ejecutada in mediatamente, **puede** recibir el resto del XRP o token solicitado después cuando la oferta sea consumida por otras transacciones [Payment][] y [OfferCreate][] de la cuenta.
+ - Si la cuenta envía una transacción OfferCreate que no está completamente ejecutada in mediatamente, **puede** recibir el resto del XRP o token solicitado después cuando la oferta sea consumida por otras transacciones [Payment][] y [OfferCreate][] de la cuenta.
- Si la cuenta ha creado cualquier línea de confianza (trust lines) sin la marca [No Ripple flag](../tokens/fungible-tokens/rippling.md) activada, o ha activado el flag Default Ripple y emitido una moneda, la cuenta **puede** recibir los tokens de esas trust lines en [transacciones Payment][] como resultado del rippling. No puede ser el destino de esas transacciones.
- En general, una cuenta en el XRP Ledger **no puede** recibir divisas no-XRP en el XRP Ledger mientras que lo siguiente sea cierto. (Esta regla no es específica del flag DepositAuth.)
- - La cuenta no ha creado trust lines con límites distintos a cero.
- - La cuenta no ha emitido tokens en trust lines creadas por otros.
- - La cuenta no ha generado ninguna oferta.
+ - La cuenta no ha creado trust lines con límites distintos a cero.
+ - La cuenta no ha emitido tokens en trust lines creadas por otros.
+ - La cuenta no ha generado ninguna oferta.
La siguiente tabla resume cuando un tipo de transacción puede depositar dinero con DepositAuth activado o desactivado:
{% partial file="/docs/_snippets/depositauth-semantics-table.md" /%}
-
-
## Activar o desactivar Deposit Authorization
Una cuenta puede activar la autorización de depositar enviando una [transacción AccountSet][] con el campo `SetFlag` con el valor de `asfDepositAuth` (9). La cuenta puede desactivar la autorización de depositar enviando una [transacción AccountSet][] con el campo `ClearFlag` con el valor de `asfDepositAuth` (9). Para más información sobre flags en AccountSet, consultar [AccountSet flags](../../references/protocol/transactions/types/accountset.md).
@@ -72,7 +71,7 @@ Una cuenta puede activar la autorización de depositar enviando una [transacció
Para ver cuando una cuenta tiene Deposit Authorization activado, utiliza el [método account_info][] para mirar en la cuenta. Compara el valor de los campos `Flags` (en el objeto `result.account_data`) con los [bitwise flags definidos para un objeto de ledger AccountRoot ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md).
-Si el resultado de los valores bitwise `Flags` Y el valor del flag `lsfDepositAuth` (`0x01000000`) es distinto a cero, entonces la cuenta tiene el DepositAuth activado. Si el resultado es cero, entonces la cuenta tiene DepositAuth desactivado.
+Si el resultado de los valores bitwise `Flags` Y el valor del flag `lsfDepositAuth` (`0x01000000`) es distinto a cero, entonces la cuenta tiene el DepositAuth activado. Si el resultado es cero, entonces la cuenta tiene DepositAuth desactivado.
## Preautorización
@@ -101,7 +100,6 @@ Puedes utilizar el [método deposit_authorized][] para ver si una cuenta esta au
- Si la cuenta de destino requiere de Deposit Authorization. (Si no requiere de autorización, todas las cuentas de origen son consideradas autorizadas.)
- Si la cuenta de origen es preautorizada para enviar dinero al destino.
-
## Ver también
- La referencia [transación DepositPreauth][].
@@ -113,7 +111,6 @@ Puedes utilizar el [método deposit_authorized][] para ver si una cuenta esta au
- [Pagos parciales](../payment-types/partial-payments.md) provee una forma para que cuentas puedan devolver pagos no deseados restando los [costes de transferencia](../tokens/fungible-tokens/transfer-fees.md) y los ratios de exchanges de la cantidad enviada en lugar de sumarlos a la cantidad enviada.
-
[enmienda DepositPreauth]: /resources/known-amendments.md#depositpreauth
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/accounts/index.md b/@l10n/es-ES/docs/concepts/accounts/index.md
index 4bbf850e8e..5c39bb6d9b 100644
--- a/@l10n/es-ES/docs/concepts/accounts/index.md
+++ b/@l10n/es-ES/docs/concepts/accounts/index.md
@@ -2,68 +2,64 @@
html: accounts.html
parent: concepts.html
seo:
- description: Aprende sobre cuentas en el XRP Ledger. AccouLas cuentas pueden enviar transacciones y almacenar XRP.
+ description: Aprende sobre cuentas en el XRP Ledger. AccouLas cuentas pueden enviar transacciones y almacenar XRP.
labels:
- Cuentas
- Pagos
---
+
# Cuentas
Una "Cuenta" en el XRP Ledger representa a un titular de XRP y a un emisor de [transacciones](../../references/protocol/transactions/index.md).
Una cuenta consiste en una dirección, un balance en XRP, un número de secuencia y un historial de sus transacciones. Para poder enviar transacciones, el dueño también necesita uno o más pares de claves criptográficas asociadas con la cuenta.
-
## Estructura de la cuenta
- Los elementos principales de una cuenta son:
+Los elementos principales de una cuenta son:
- Una **cuenta** identificable, como `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`.
- Un **balance en XRP**. Parte de este XRP se aparte para la [Reserva](reserves.md).
- Un **número de secuencia**, el cual ayuda a asegurar que cualquier transacción que esta cuenta envíe se aplique en el orden correcto y solo una vez. Para ejecutar una transacción, el número de secuencia de la transacción y el número de secuencia de su remitente deben coincidir. Después, como parte de la aplicación de la transacción, el número de secuencia de la cuenta incrementa en 1. (Ver también: [Tipos de datos básicos: Secuencia de cuenta](../../references/protocol/data-types/basic-data-types.md#account-sequence).)
- Un **histórico de transacciones** que afectaron a la cuenta y sus balances.
- Una o más maneras de [autorizar transacciones](../transactions/index.md#authorizing-transactions), posiblemente incluyendo:
- - Un par de claves maestras intrínseco a la cuenta. (Esto puedes desactivarse pero no cambiarse.)
- - Una par de claves "normales" ("regular" en inglés) que se pueden rotar.
- - Una lista de firmantes para [multi-firma](multi-signing.md). (Almacenado por separado de los datos principales de la cuenta.)
+ - Un par de claves maestras intrínseco a la cuenta. (Esto puedes desactivarse pero no cambiarse.)
+ - Una par de claves "normales" ("regular" en inglés) que se pueden rotar.
+ - Una lista de firmantes para [multi-firma](multi-signing.md). (Almacenado por separado de los datos principales de la cuenta.)
Los datos principales de una cuenta se guardan en una entrada del ledger [AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md). Una cuenta puede ser también el dueña (o parcialmente dueña) de varios otros tipos de entradas del ledger.
**Consejo:** Una "Cuenta" en el XRP Ledger está en algún lugar entre el uso financiero (como una "cuenta bancaria") y el uso informático (como una "cuenta UNIX"). Las monedas y activos no XRP no se guardan en una cuenta del XRP Ledger en sí misma; cada uno de estos activos se almacena en una relación contable llamada "Línea de confianza" (trust line en inglés) que conecta a dos partes.
-
## Creación de cuentas
No hay una transacción dedicada a "crear una cuenta". La [transacción Payment][] automáticamente crea una nueva cuenta si el pago envía suficiente XRP a una dirección matemáticamente válida que aún no tiene una cuenta. Esto se llama _finnaciar_ una cuenta, y crea una [entrada AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) en el ledger. No hay otra transacción que cree una cuenta.
-**Atención:** Financiar una cuenta **no te da** privilegios especiales sobre esa cuenta. Quien tenga la clave secreta correspondiente a la dirección de la cuenta tiene control total sobre la cuenta y todo el XRP que contiene. Para algunas direcciones, es posible que nadie tenga la clave secreta, en este caso la cuenta es un agujero negro [black hole](addresses.md#special-addresses) y el XRP se pierde para siempre.
+**Atención:** Financiar una cuenta **no te da** privilegios especiales sobre esa cuenta. Quien tenga la clave secreta correspondiente a la dirección de la cuenta tiene control total sobre la cuenta y todo el XRP que contiene. Para algunas direcciones, es posible que nadie tenga la clave secreta, en este caso la cuenta es un agujero negro [black hole](addresses.md#special-addresses) y el XRP se pierde para siempre.
La forma típica de obtener una cuenta en el XRP Ledger es la siguiente:
1. Genera un par de claves desde una fuente de fuerte aleatoriedad y calcula la dirección de ese par de claves.
2. Hacer que alguien que ya tenga una cuenta en el XRP Ledger envíe XRP a la dirección que generaste.
+ - Por ejemplo, puedes comprar XRP en un exchange privado, después retirar el XRP del exchange a la dirección que especificaste.
- - Por ejemplo, puedes comprar XRP en un exchange privado, después retirar el XRP del exchange a la dirección que especificaste.
-
- **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente {% $env.PUBLIC_BASE_RESERVE %}), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
-
-
+ **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente {% $env.PUBLIC_BASE_RESERVE %}), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
## Ver también
- **Conceptos:**
- - [Reservas](reserves.md)
- - [Claves criptográficas](cryptographic-keys.md)
- - [Cuentas emisoras y operacionales](account-types.md)
+ - [Reservas](reserves.md)
+ - [Claves criptográficas](cryptographic-keys.md)
+ - [Cuentas emisoras y operacionales](account-types.md)
- **Referencias:**
- - [Método account_info][]
- - [Método wallet_propose][]
- - [Transacción AccountSet][]
- - [Transacción Payment][]
- - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+ - [Método account_info][]
+ - [Método wallet_propose][]
+ - [Transacción AccountSet][]
+ - [Transacción Payment][]
+ - [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
- **Tutoriales:**
- - [Administrar configuración de la cuenta (Categoría)](../../tutorials/how-tos/manage-account-settings/index.md)
- - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+ - [Administrar configuración de la cuenta (Categoría)](../../tutorials/how-tos/manage-account-settings/index.md)
+ - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/accounts/multi-signing.md b/@l10n/es-ES/docs/concepts/accounts/multi-signing.md
index 3bee2e4d0d..820c049e4c 100644
--- a/@l10n/es-ES/docs/concepts/accounts/multi-signing.md
+++ b/@l10n/es-ES/docs/concepts/accounts/multi-signing.md
@@ -2,11 +2,12 @@
html: multi-signing.html
parent: accounts.html
seo:
- description: Utiliza la firma múltiple para mayor seguridad enviando transacciones.
+ description: Utiliza la firma múltiple para mayor seguridad enviando transacciones.
labels:
- Smart Contracts
- Seguridad
---
+
# Multi-Signing
La firma múltiple o multi-signing en el XRP Ledger es un método para [autorizar transacciones](../transactions/index.md#authorizing-transactions) para el XRP Ledger usando una combinación de múltiples claves secretas. Puedes tener cualquier combinación de métodos de autorización activados para tu dirección, incluido el multi-signing, un [par de claves maestras](cryptographic-keys.md#par-de-claves-maestras), y un [par de claves normales](cryptographic-keys.md#par-de-claves-normales). (El único requisito es que _al menos un_ método debe estar activado.)
@@ -34,13 +35,13 @@ Asignas un peso a cada firmantes de la lista. El peso representa la autoridad de
El valor cuórum de una lista es una peso mínimo total requerido para autorizar la transacción. El cuórum debe ser mayor a 0 pero menor o igual a la suma de los valores de los pesos en la lista de firmantes: lo que significa, que debe ser posible conseguir un cuórum con los pesos de firmante dados.
### Localizador de cartera
+
También puedes añadir hasta 256 bits de datos arbitrarios para cada entrada por firmante de la lista. Estos datos no son necessarios o usados por la red, pero pueden ser utilizados por smart contracts u otras aplicaciones para identificar o confirmar otros datos sobre los firmantes.
_(Añadido en la [enmienda ExpandedSignerList][].)_
-
### Ejemplos uitilzando Signer Weight y Quorum
Los pesos y el cuórum te permiten establecer un nivel apropiado de supervisión para cada transacción, en función de la confianza relativa y la autoridad relegada a los responsables que administran la cuenta.
@@ -55,32 +56,31 @@ En cada uno de los tres ejemplos anteriores, deshabilitarías la clave maestra s
Podría darse el caso donde crees una lista de multi firma como "plan de respaldo". El dueño de la cuenta normalmente usa la clave normal para sus transacciones (no una clave multi-signing). Por seguridad, el propietario añade una lista de firmantes que contiene a 3 amigos, los tres con un peso de 1, y un cuórum de 3. Si el propietario de la cuenta perdiese la clave privada, puede pedir a sus amigos que multi firmen una transacción para reemplazar la clave normal.
-
## Mandar transacciones Multi-Signed
Para enviar transacciones multi-signed de forma satisfactoria, debes de hacer todo lo siguiente:
-* La dirección que envía la transacción (especificada en el campo `Account`) debe tener un [objeto `SignerList` en el ledger ](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md). Para instrucciones de cómo hacer esto, ver [Set Up Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md).
-* La transacción debe incluir el campo `SigningPubKey` como un valor vacío.
-* La transacción debe incluir el [campo `Signers`](../../references/protocol/transactions/common-fields.md#signers-field) conteniendo un array de firmas.
-* Las firmas presentadas en el array `Signers` debe coincidir con los firmantes definidos en la `SignerList`.
-* Para las firmas presentadas, el peso total asociado con esos firmantes debe ser igual o mayor al cuórum de la `SignerList`.
-* El [coste de transacción](../transactions/transaction-cost.md) (especificado en el campo `Fee`) debe ser al menos (N+1) veces el coste de una transacción normal, donde N es el número de firmas presentadas.
-* Todos los campos de la transacción deben ser definidos antes de recolectar las firmas. No puedes [auto-rellenar](../../references/protocol/transactions/common-fields.md#auto-fillable-fields) los campos.
-* Si se presenta en forma binaria, el array de `Signers` debe estar ordenado en base al valor números de las direcciones de los firmantes, con el valor menor, primero . (Si se envía como JSON, el [método submit_multisigned][] se ocupa de ello automáticamente.)
+- La dirección que envía la transacción (especificada en el campo `Account`) debe tener un [objeto `SignerList` en el ledger ](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md). Para instrucciones de cómo hacer esto, ver [Set Up Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md).
+- La transacción debe incluir el campo `SigningPubKey` como un valor vacío.
+- La transacción debe incluir el [campo `Signers`](../../references/protocol/transactions/common-fields.md#signers-field) conteniendo un array de firmas.
+- Las firmas presentadas en el array `Signers` debe coincidir con los firmantes definidos en la `SignerList`.
+- Para las firmas presentadas, el peso total asociado con esos firmantes debe ser igual o mayor al cuórum de la `SignerList`.
+- El [coste de transacción](../transactions/transaction-cost.md) (especificado en el campo `Fee`) debe ser al menos (N+1) veces el coste de una transacción normal, donde N es el número de firmas presentadas.
+- Todos los campos de la transacción deben ser definidos antes de recolectar las firmas. No puedes [auto-rellenar](../../references/protocol/transactions/common-fields.md#auto-fillable-fields) los campos.
+- Si se presenta en forma binaria, el array de `Signers` debe estar ordenado en base al valor números de las direcciones de los firmantes, con el valor menor, primero . (Si se envía como JSON, el [método submit_multisigned][] se ocupa de ello automáticamente.)
## Ver también
- **Tutoriales:**
- - [Configurar Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
- - [Envíar una transacción Multi-Signed](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
+ - [Configurar Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
+ - [Envíar una transacción Multi-Signed](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
- **Conceptos:**
- - [Claves criptográficas](cryptographic-keys.md)
- - [Coste de transacción especial para transacciones Multi-signed](../transactions/transaction-cost.md#special-transaction-costs)
+ - [Claves criptográficas](cryptographic-keys.md)
+ - [Coste de transacción especial para transacciones Multi-signed](../transactions/transaction-cost.md#special-transaction-costs)
- **Referencias:**
- - [Transacción SignerListSet][]
- - [Objeto SignerList](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
- - [método sign_for][]
- - [método submit_multisigned][]
+ - [Transacción SignerListSet][]
+ - [Objeto SignerList](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
+ - [método sign_for][]
+ - [método submit_multisigned][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/accounts/reserves.md b/@l10n/es-ES/docs/concepts/accounts/reserves.md
index bc7ae9d7b5..0dc78f91ec 100644
--- a/@l10n/es-ES/docs/concepts/accounts/reserves.md
+++ b/@l10n/es-ES/docs/concepts/accounts/reserves.md
@@ -2,12 +2,13 @@
html: reserves.html
parent: accounts.html
seo:
- description: Las cuentas XRP Ledger exigen una reserva de XRP para reducir el spam en la información del ledger.
+ description: Las cuentas XRP Ledger exigen una reserva de XRP para reducir el spam en la información del ledger.
labels:
- Comisiones
- Cuentas
top_nav_grouping: Páginas populares
---
+
# Reservas
El XRP Ledger aplica un _requisito de reserva_, en XRP, para proteger el ledger global compartido de crecer excesivamente como resultado del spam o del uso malicioso. El objetivo es limitar el crecimiento del ledger para coincida con las mejoras tecnológicas de tal forma que un equipo basico actual pueda siempre tener el ledger actual en RAM.
@@ -20,8 +21,8 @@ El requisito de reserva cambia de tanto en tanto debido al proceso de [Votación
Los requisito de reserva consta de dos partes:
-* La **reserva base** es la cantidad mínima de XRP que es necesaria para cada dirección en el ledger.
-* La **reserva de propietario** es un incremento del requisito de reserva por cada objeto que la dirección posee en el ledger. El coste por artículo se le conoce como _reserva incremental_.
+- La **reserva base** es la cantidad mínima de XRP que es necesaria para cada dirección en el ledger.
+- La **reserva de propietario** es un incremento del requisito de reserva por cada objeto que la dirección posee en el ledger. El coste por artículo se le conoce como _reserva incremental_.
Los requerimientos de reserva actuales en Mainnet son:
@@ -48,7 +49,7 @@ Algunos casos especiales:
Las aplicaciones pueden buscar los valores de las reservas base e incremental actuales utilizando el [método server_info][] o el [método server_state][]:
| Método | Unidades | Campo de reserva base | Campo de reserva incremental |
-|-------------------------|----------------------|-------------------------------------|------------------------------------|
+| ----------------------- | -------------------- | ----------------------------------- | ---------------------------------- |
| [método server_info][] | Decimal XRP | `validated_ledger.reserve_base_xrp` | `validated_ledger.reserve_inc_xrp` |
| [método server_state][] | Drops enteros de XRP | `validated_ledger.reserve_base` | `validated_ledger.reserve_inc` |
@@ -56,7 +57,6 @@ Para determinar las reservas de propietario de una cuenta, hay que multiplicar l
Para calcular el requisito total de direcciones, multiplica `OwnerCount` por `reserve_inc_xrp`, y luego suma `reserve_base_xrp`. [Aquí tienes una demostración](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#codeblock-17) del cálculo en Python.
-
## Quedarse por debajo del requisito de reserva
Durante el procesamiento de transacciones, el [coste de transacción](../transactions/transaction-cost.md) destruye parte del XRP del saldo de la dirección que envía la transacción. Esto puede causar que una dirección XRP se quede por debajo del requisito de reserva. Puedes incluso destruir _todo_ tu XRP de esta forma.
@@ -65,7 +65,6 @@ Cuando tu cuenta posee menos XRP XRP que el requisito actual de reserva, no pued
**Consejo:** Si tu dirección está debajo del requisito de reserva, puedes enviar unas [transacciones OfferCreate][] para aadquirir más XRP y volver a superar el requisito de reeerva. Sin embargo, dado que no puedes crear una [entrada en el ledger Offer](../../references/protocol/ledger-data/ledger-entry-types/offer.md) cuando estás por debajo de la reserva, esta transacción puede consumir solo Offers que ya esté en el libro de ordenes.
-
## Cambiar los requisitos de reserva
El XRP Ledger tiene un mecanismo para ajustar los requisitos de reserva. Estos ajustes pueden considerar, por ejemplo, cambios a largo plazo del valor de XRP, mejoras en la capacidad del hardware de los equipos convencionales, o una eficiencia incrementada en la implementación del software del servidor. Cualquier cambio tiene que ser aprobado por un proceso de consenso. Ver [Votación de fee](../consensus-protocol/fee-voting.md) para más información.
diff --git a/@l10n/es-ES/docs/concepts/accounts/tickets.md b/@l10n/es-ES/docs/concepts/accounts/tickets.md
index 10f9fd6bf8..2cfc971673 100644
--- a/@l10n/es-ES/docs/concepts/accounts/tickets.md
+++ b/@l10n/es-ES/docs/concepts/accounts/tickets.md
@@ -2,11 +2,12 @@
html: tickets.html
parent: accounts.html
seo:
- description: Envía transacciones en un orden no secuencial.
+ description: Envía transacciones en un orden no secuencial.
labels:
- Cuentas
- Enviar transacciones
---
+
# Tickets
_(Añadido por la [enmienda TicketBatch][].)_
@@ -25,18 +26,17 @@ Sin embargo, hay situaciones donde los números de secuencia son demasiado limit
Los Tickets facilitan una solución para todos estos problemas apartando números de secuencia que se pueden uitlizar más adelante, fuera de su orden normal, pero aún así no más de una vez cada uno.
-
## Los tickets son números de secuencia reservados
Un Ticket es un registro de que se ha apartado un número de secuencia para utilizar más adelante. Una cuenta envía primero una [transacción TicketCreate][] para apartar una o más números de secuencia como Tickets; esto deja un registro en los [datos de estado del ledger](../ledgers/index.md), en la forma de un [objeto Ticket][], para cada número de secuencia reservado.
Los Tickets están numerados usando los números de secuencia que han sido apartado para crearlos. Por ejemplo, si un número de secuencia de cuenta actual es 101 y has creado 3 Tickets, esos Tickets tienen los números de secuencia de Ticket 102, 103, y 104. Haciendo esto se incrementa el número de secuencia de la cuenta a 105.
-[{% inline-svg file="/docs/img/ticket-creation.svg" /%}](/docs/img/ticket-creation.svg "Diagrama: Creación de tres tickets")
+[{% inline-svg file="/docs/img/ticket-creation.svg" /%}](/docs/img/ticket-creation.svg 'Diagrama: Creación de tres tickets')
Más tarde, puedes enviar una transacción utilizando un Ticket específico en vez de un número de secuencia; haciendo eso eliminas el Ticket correspondiente de los datos de estado del ledger y no cambia el número de secuencia normal de tu cuenta. También puedes todavía enviar transacciones utilizando el números de secuencia normal sin utilizar Tickets. Puedes utilizar cualquiera de tus Tickets disponibles en cualquier orden en cualquier momento, pero cada Ticket puede utilizarse solo una vez.
-[{% inline-svg file="/docs/img/ticket-usage.svg" /%}](/docs/img/ticket-usage.svg "Diagrama: Usando el ticket 103.")
+[{% inline-svg file="/docs/img/ticket-usage.svg" /%}](/docs/img/ticket-usage.svg 'Diagrama: Usando el ticket 103.')
Continuando con el ejemplo anterior, puedes enviar una transacción utilizando el número de secuencia 105 o cualquiera de los tres Tickets que has creado. Si envías una transacción utilizando el Ticket 103, esto eliminará el Ticket 103 del ledger. Tu próxima transacción despues de esa puede uitlizar el número de secuencia 105, el Ticket 102, o el Ticket 104.
@@ -59,15 +59,14 @@ Cualquier cuenta puede crear y utilizar Tickets en cualquier tipo de transaccion
## Ver también
-
- **Conceptos:**
- - [Multi-Signing](multi-signing.md)
+ - [Multi-Signing](multi-signing.md)
- **Tutoriales:**
- - [Usar Tickets](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
+ - [Usar Tickets](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
- **Referencias:**
- - [Transacción TicketCreate][]
- - [Campos comunes de una transacción](../../references/protocol/transactions/common-fields.md)
- - [Objeto Ticket](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
- - [Método account_objects ][]
+ - [Transacción TicketCreate][]
+ - [Campos comunes de una transacción](../../references/protocol/transactions/common-fields.md)
+ - [Objeto Ticket](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
+ - [Método account_objects ][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
index 5f347840bb..851a7caeac 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
@@ -2,10 +2,11 @@
html: consensus-principles-and-rules.html
parent: consensus.html
seo:
- description: Las reglas y principios del algoritmo de consenso que permite a los usuarios para transferir fondos (incluidas divisas fiat, divisas digitales y cualquier otra forma de valor) a través de fronteras nacionales igual de facil que enviar un correo electrónico.
+ description: Las reglas y principios del algoritmo de consenso que permite a los usuarios para transferir fondos (incluidas divisas fiat, divisas digitales y cualquier otra forma de valor) a través de fronteras nacionales igual de facil que enviar un correo electrónico.
labels:
- Blockchain
---
+
# Los principios y reglas del consenso
El XRP Ledger es un sistema de pagos universal que permite a los usuarios transferir fondos a través de fronteras nacionales de la misma forma que se envía un correo electrónico. Como otras redes de pagos peer-to-peer como Bitcoin, el XRP Ledger permite transacciones de liquidación peer-to-peer a través de una red descentralizada de ordenadores. A diferencia de otros protocolos de divisas digitales, el XRP Ledger permite a los usuarios denominar sus transacciones con cualquier divisa que prefieran, incluyendo divisas fiat, divisas digitales y cualquier otra forma de valor, y XRP (el activo nativo del XRP Ledger).
@@ -20,7 +21,6 @@ Principalmente, el XRP Ledger es una base de datos compartida que registra infor
Como sistema criptográfico, los dueños de cuentas del XRP Ledger son identificados como _identidades criptográficas_, las cuales corresponden a pares de claves públicas/privadas. Las transacciones son autorizadas por firmas criptográficas que coinciden con esas identidades. Cada servidor procesa cada transacción de acuerdo con las mismas reglas deterministas conocidas. Finalmente, el objetivo es para cada servidor en la red tener una copia completa de exactamente el estado del mismo ledger, sin necesidad de una única autoridad central que arbitre las transacciones.
-
### El problema del doble gasto
El problema del "doble gasto" es un desafío fundamental para cualquier sistema de pagos digital. El problema viene del requisito de que cuando el dinero es gastado en un sitio, no puede ser gastado en otro lugar. Generalmente, el problema ocurre cuando tiene dos transacciones cualesquiera de las cuales una es válida pero no ambas juntas.
@@ -33,7 +33,6 @@ Convencionalmente, los sistemas de pagos resuelven el problema del doble gasto t
Las tecnologías de contabilidad distribuida, como el XRP Ledger, no tiene una autoridad central. Estas tecnologías deben resolver el problema del doble gasto de alguna otra forma.
-
## Cómo funciona el consenso
### Simplificando el problema
@@ -56,14 +55,14 @@ La función principal del consenso es que los participantes en el proceso acuerd
1. Si no hay ninguna razón por la que una transacción debería no estar incluida en dicho grupo de transacciones, todos los participantes honestos aceptan incluirla. Si todos los participantes ya están de acuerdo, el consenso no tiene trabajo que hacer.
2. Si hay alguna razón por la que una transacción no debe incluirse en dicho grupo de transacciones, todos los participantes honestos estarán dispuestos a excluirla. Si la transacción todavía es válida, no hay razón para incluirla en la siguiente ronda, y todos deberían aceptar incluirla en ese momento.
-3. Es extremadamente raro para un participante que le importe cómo las transacciones fueron agrupadas. El acuerdo es más fácil cuando la prioridad de cualquiera es llegar a un acuerdo y sólo desafiarlo cuando hay intereses divergentes.
+3. Es extremadamente raro para un participante que le importe cómo las transacciones fueron agrupadas. El acuerdo es más fácil cuando la prioridad de cualquiera es llegar a un acuerdo y sólo desafiarlo cuando hay intereses divergentes.
4. Las reglas deterministas pueden ser usadas incluso para formar agrupaciones, llegando a desacuerdos solo en los casos extremos. Por ejemplo, si hay dos transacciones conflictivas en una ronda, las reglas deterministas pueden ser utilizadas para determinar cuál se incluye en la siguiente ronda.
La principal prioridad de cada participante es la exactitud. Primero deben hacer cumplir las reglas para estar seguros de que nadie viola la integridad del ledger compartido. Por ejemplo, una transacción que no está correctamente firmada nunca debe ser procesada (incluso si otros participantes quieren que se procese). Sin embargo, la segunda prioridad de cada participante honesto es el llegar a un acuerdo. Una red con posibles gastos dobles no tiene ninguna utilidad, así que cada participante honesto valora el acuerdo por encima de la exactitud.
### Rondas de consenso
-Una ronda de consenso es una intento de ponerse de acuerdo en un grupo de transacciones para que puedan ser procesadas. Una ronda de consenso empieza con cada participante que lo desea tomando una posición inicial. Este es el conjunto de transacciones válidas que han visto.
+Una ronda de consenso es una intento de ponerse de acuerdo en un grupo de transacciones para que puedan ser procesadas. Una ronda de consenso empieza con cada participante que lo desea tomando una posición inicial. Este es el conjunto de transacciones válidas que han visto.
Después, los participantes se "avalanzan" al consenso: Si una transacción particular no tiene apoyo mayoritario, los participantes concuerdan apartar esa transacción. Si una transacción en concreto sí tiene el apoyo mayoritario, los participantes concuerdan incluir esa transacción. Así leves mayorías rápidamente consiguen apoyo completo y leves minorías rápidamente consiguen rechazo universal en la ronda actual.
@@ -73,7 +72,7 @@ Cuando un participante ve a una sobremayoría que está de acuerdo en el conjunt
### El consenso puede fallar
-No es práctico desarrollar un algoritmo de consenso que nunca falla para alcanzar un consenso perfecto. Para entender el por qué, considera cómo finaliza el proceso de consenso. En algún momento, cada participante debe declarar que ha alcanzado consenso y que un grupo de transacciones conocido ha sido el resultado de ese proceso. Esta declaración compromete al participante de que un particular grupo de transacciones como resultado de ese proceso de consenso.
+No es práctico desarrollar un algoritmo de consenso que nunca falla para alcanzar un consenso perfecto. Para entender el por qué, considera cómo finaliza el proceso de consenso. En algún momento, cada participante debe declarar que ha alcanzado consenso y que un grupo de transacciones conocido ha sido el resultado de ese proceso. Esta declaración compromete al participante de que un particular grupo de transacciones como resultado de ese proceso de consenso.
Algún participante debe hacer esto primero o ningún participante podrá hacerlo nunca, y nunca llegarán a alcanzar consenso. Ahora, considera al participante que hace esto primero. Cuando este participante decide que el consenso ha finalizado, otros participantes no han llegado todavía a tomar esa decisión. Si fuesen incapaces de cambiar el conjunto acordado desde su punto de vista, ellos habrían decidido que el consenso se había alacanzado ya. Por lo que deben todavía ser capaces de cambiar el conjunto agregado..
@@ -114,18 +113,18 @@ El algoritmo de consenso del XRP Ledger provee una alternativa robusta a sistema
## Ver también
- **Conceptos:**
- - [Consenso](index.md)
- - [Investigación del consenso](consensus-research.md)
- - [Vídeo del mecanismo de consenso del XRPL](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
+ - [Consenso](index.md)
+ - [Investigación del consenso](consensus-research.md)
+ - [Vídeo del mecanismo de consenso del XRPL](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
- **Tutoriales:**
- - [Envío de transacciones confiable](../transactions/reliable-transaction-submission.md)
- - [Ejecutar `rippled` como Validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+ - [Envío de transacciones confiable](../transactions/reliable-transaction-submission.md)
+ - [Ejecutar `rippled` como Validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
- **Referencias:**
- - [Referencia del formato ledger](../../references/protocol/ledger-data/index.md)
- - [Referencia del formato de transacción](../../references/protocol/transactions/index.md)
- - [método consensus_info][]
- - [método validator_list_sites][]
- - [método validators][]
- - [método consensus_info][]
+ - [Referencia del formato ledger](../../references/protocol/ledger-data/index.md)
+ - [Referencia del formato de transacción](../../references/protocol/transactions/index.md)
+ - [método consensus_info][]
+ - [método validator_list_sites][]
+ - [método validators][]
+ - [método consensus_info][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md
index d3d6025a19..587c76399e 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md
@@ -1,14 +1,15 @@
---
seo:
- description: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
+ description: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
labels:
- Blockchain
---
+
# Protecciones del consenso contra ataques y modos de fallo
El Protocolo de Consenso del XRP Ledger es un mecanismo de consenso _tolerante a fallos bizantinos_, lo que quiere decir que está diseñado para trabajar incluso si todo tipo de cosas salen mal: los participantes dependen de una red abierta poco confiable, y actores maliciosos pueden estar intentando controlar o interrumpir el sistema en un momento dado. Encima de eso, el conjunto de participantes en el Protocolo de Consenso del XRP Ledger no se conoce de antemano y puede cambiar con el tiempo.
-Confirmar transacciones de una forma rápida mientras se mantiene las propiedades deseadas de la red es un desafío complejo, y es imposible construir un sistema perfecto. El Protocolo de Conenso del XRP Ledger está diseñado para funcionar lo mejor posible en la mayoría de las situaciones, y para fallar elegántemente en aquellas que no es posible.
+Confirmar transacciones de una forma rápida mientras se mantiene las propiedades deseadas de la red es un desafío complejo, y es imposible construir un sistema perfecto. El Protocolo de Conenso del XRP Ledger está diseñado para funcionar lo mejor posible en la mayoría de las situaciones, y para fallar elegántemente en aquellas que no es posible.
Esta página describe algunos de los desafíos que el Protocolo de Consenso del XRP LEdger se encuentra y cómo se enfrenta a ellos.
@@ -28,7 +29,6 @@ Si más del 20% de los validadores son inalcanzables o no se comportan adecuadam
La única forma de confirmar una transacción inválida sería conseguir que el 80% de los validadores confiables aprueben la transacción y estén de acuerdo en el resultado exacto. (Las transacciones inválidas incluyen ese dinero gastado que ya ha sido gastado, o de otra forma estaría rompiendo las reglas de la red.) En otras palabras, una gran mayoría de los validadores confiables habrían _colisionado_. Con docenas de validadores confiables corriendo por diferentes personas y negocios en diferentes partes del mundo, esto es muy dificil de conseguir intencionadamente.
-
## Vulnerabilidades de software
Como con cualquier sistema de software, los bugs (o código intencionalmente malicioso) en la implementación del Protocolo de Consenso del XRP Ledger, los paquetes de software comúnmente implementados, o sus dependencias, son un problema que hay que tomarse seriamente. Incluso los bugs que causan que un servidor falle cuando ve valores de entrada cocinados pueden abusasrse para interrumpir el proceso de la red. Los desarrolladores del XRP Ledger toman precauciones para abordar esta amenaza en la referencia de implementaciones de software de XRP Ledger, incluyen:
@@ -39,21 +39,18 @@ Como con cualquier sistema de software, los bugs (o código intencionalmente mal
- Revisiones profesionales encargadas periodicamentes para detectar vulnerabilidades e inseguridades.
- Un [programa de recompensas de bugs](https://ripple.com/bug-bounty/) que premia a investigadores de seguridad que revelan responsablemente las vulnerabilidades.
-
## Ataques Sybil
Un _[ataque Sybil](https://en.wikipedia.org/wiki/Sybil_attack)_ es un intento de tomar el control de una red usando un gran número de identidades falsas. En el XRP Ledger, un ataque Sybil tomaría la forma de ejecutar un gran número de validadores, y luego convencer a otros de confiar en esos validadores. Este tipo de ataques son teóricamente posibles, pero sería muy dificil de hacer porque la intervención humana es necesaria para ser confiados por otros.
-No importa cuantos servidores un atacante ejecuta, esos servidores no tienen voz ni voto sobre lo que los participantes existentes consideran validados a no ser que esos participantes decidan confiar en los validadores del atacante. Otros servidores solo escuchan lo que los validadores que tienen configurados para confiar, ya sea por una lista de validodres o una configuración explícita. (Ver [requisitos de superposición de validador](#requisitos-de-superposición-del-validador) para un sumario de cómo una lista de validadores funciona.)
+No importa cuantos servidores un atacante ejecuta, esos servidores no tienen voz ni voto sobre lo que los participantes existentes consideran validados a no ser que esos participantes decidan confiar en los validadores del atacante. Otros servidores solo escuchan lo que los validadores que tienen configurados para confiar, ya sea por una lista de validodres o una configuración explícita. (Ver [requisitos de superposición de validador](#requisitos-de-superposición-del-validador) para un sumario de cómo una lista de validadores funciona.)
Esta confianza no ocurre automáticamente, para realizar un ataque Sybil exitosamente habría que añadirle el laborioso trabajo de convencer a personas y empresas de reconfigurar sus servidores XRP Ledger para confiar en los validadores del atacante. Incluso en el caso de que una entidad individual sea engañada haciendo eso, esto tendrá un impacto mínimo en otros que no han cambiado sus configuraciones.
-
## Ataque del 51%
Un "ataque de 51%" es un ataque en un sistema blockchain donde un bando controla más del 50% de todo el poder de minado o votación. (Técnicamente, el ataque está incorrectamente llamado porque _cualquier_ valor superior al 50% es suficiente.) El XRP Ledger no es vulnerable a un ataque del 51% porque no utiliza minería en su mecanismo de consenso. La analogía más cercana para el XRP Ledger es un [ataque Sybil](#ataques-sybil), el cuál sería complicado de realizar.
-
## Requisitos de superposición del validador
Para todos los participantes en el XRP Ledger se pongan de acuerdo en qué consideran como validado, deben empezar eligiendo un conjunto de validadores confiables que son muy parecidos a los conjuntos elegidos por los demás. En el peor escenario, menos del 90% de superposición podría causar que algunos participantes diverjan entre ellos. Por esa razón, existen listas firmadas de validadores recomendados, destinadas a incluir servidores bien mantenidos y confiables administrados por la industria y la comunidad.
@@ -64,7 +61,6 @@ Técnicamente, si ejecutas un servidor, puedes configurar tu propia lista o expl
Se está investigando un nuevo diseño del protocolo de consenso mejorado que permita listas de validadores más hetereogeneas. Para más información, ver la [Investigación del consenso](consensus-research.md) page.
-
## Ver también
- Para una descripción detallada del protocolo de consenso, ver [Consenso](index.md).
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-research.md b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-research.md
index f05bcc5eb3..ddf9121727 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-research.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-research.md
@@ -2,18 +2,19 @@
html: consensus-research.html
parent: consensus.html
seo:
- description: Artículos académicos sobre algoritmos de consenso investigaciones relacionadas.
+ description: Artículos académicos sobre algoritmos de consenso investigaciones relacionadas.
labels:
- Blockchain
---
+
# Investigación del consenso
Ripple investiga los límites teóricos y prácticos de los protocolos de consenso del XRP Ledger. La siguiente tabla enumera los artículas académicos publicados por Ripple:
-| Fecha | Título | Autores | Resumen |
-|---|---|---|---|
-| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | Introduce un novedoso algoritmo de transmisión a nivel atómico llamado Cobalt que permite más flexibilida d de consenso en las UNL. |
-| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | Un análisis actualizado y detallado del algoritmo de consenso del XRP Ledger y sus propiedad de seguridad y actividad. |
-| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | Introduce el algoritmo de consenso detrás del XRP Ledger. |
+| Fecha | Título | Autores | Resumen |
+| ---------- | --------------------------------------------------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
+| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | Introduce un novedoso algoritmo de transmisión a nivel atómico llamado Cobalt que permite más flexibilida d de consenso en las UNL. |
+| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | Un análisis actualizado y detallado del algoritmo de consenso del XRP Ledger y sus propiedad de seguridad y actividad. |
+| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | Introduce el algoritmo de consenso detrás del XRP Ledger. |
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md
index 8380ea6077..b3d9a4ebd6 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md
@@ -2,19 +2,19 @@
html: consensus-structure.html
parent: consensus.html
seo:
- description: Entender el rol del consenso en el XRP Ledger.
+ description: Entender el rol del consenso en el XRP Ledger.
labels:
- Blockchain
---
+
# Estructura de consenso
-Escrito por Dave Cohen, David Schwartz, y Arthur Britto._
+Escrito por Dave Cohen, David Schwartz, y Arthur Britto.\_
Este artículo proporciona una visión a alto nivel del XRP Ledger, la información que almacena, y cómo las [transacciones](../../references/protocol/transactions/index.md) dan como resultado cambios en el ledger.
Al crear aplicaciones en el XRP Ledger, es importante entender el proceso, para no sorprenderse por el comportamiento de las APIs de XRP Ledger y sus efectos.
-
## Introducción
La red peer-to-peer XRP Ledger proporciona un libro de contabilidad (ledger) compartido a nivel mundial, que brinda información autorizada a aplicaciones sobre el estado de su contenido. Este estado de la información incluye:
@@ -27,13 +27,13 @@ La red peer-to-peer XRP Ledger proporciona un libro de contabilidad (ledger) com
Para una descripción técnica completa de todos los datos que se incluyen en una versión de un ledger, ver la [Referencia de formato de ledger](../../references/protocol/ledger-data/index.md).
-[{% inline-svg file="/docs/img/anatomy-of-a-ledger-complete.svg" /%}](/docs/img/anatomy-of-a-ledger-complete.svg "Figura 1: Elementos del XRP Ledger")
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-complete.svg" /%}](/docs/img/anatomy-of-a-ledger-complete.svg 'Figura 1: Elementos del XRP Ledger')
_Figura 1: Elementos del XRP Ledger_
El XRP Ledger tiene una nueva versión de un ledger cada ciertos segundos. Cuando la red acuerda el contenido de una nueva versión del ledger, la versión del ledger es _validado_, y sus contenidos no se pueden cambiar nunca. Las versiones validadadas de ledgers que precedieron forman el histórico del ledger. Incluso el ledger validado más reciente es parte del histórico, ya que representa el estado de la red hasta hace poco tiempo. En la actualidad, la red está evaluando transacciones que pueden aplicarse y finalizarse en la próxima versión del ledger. Mientras la evaluación está ocurriendo, la red tiene versiones de ledger que aun no están validadas.
-[{% inline-svg file="/docs/img/ledger-history.svg" /%}](/docs/img/ledger-history.svg "Figura 2: Histórico del XRP Ledger")
+[{% inline-svg file="/docs/img/ledger-history.svg" /%}](/docs/img/ledger-history.svg 'Figura 2: Histórico del XRP Ledger')
_Figure 2: Histórico del XRP Ledger_
@@ -45,13 +45,13 @@ Los cambios a nivel de usuario son el resultado de transacciones. Ejemplos de [t
Cada versión del ledger también contiene un conjunto de transacciones y metadata sobre esas transacciones. Las transacciones que incluye son solo aquellas que han sido aplicadas para la anterior versión del ledger para crear la nueva versión del ledger. Los metadatos o metadata se registran a los mismos efectos en el estado del dato del ledger.
-[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg "Figura 3: Transacciones aplicadas a la versión del ledger")
+[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg 'Figura 3: Transacciones aplicadas a la versión del ledger')
_Figure 3: Transacciones aplicadas a la versión del ledger_
El conjunto de transacciones incluidas en una instancia ledger se guardan en ese ledger y permite auditorías de la historia del XRP Ledger. Si un balance de cuenta es diferente en un ledger N+1 respecto al ledger N, entonces el ledger N+1 contiene las transacciones responsables del cambio.
-Las transacciones que aparecen en un ledger validado pueden haber logrado cambiar el ledger, o pueden haberse procesado sin haber realizado la acción requerida. Las transacciones exitosas tienen el [código resultado](../../references/protocol/transactions/transaction-results/index.md) **`tesSUCCESS`** el cual indica los cambios solicitados para aplicar en el ledger. Las transacciones fallidas en el ledger tienen el código de resultado de clase **`tec`**.1
+Las transacciones que aparecen en un ledger validado pueden haber logrado cambiar el ledger, o pueden haberse procesado sin haber realizado la acción requerida. Las transacciones exitosas tienen el [código resultado](../../references/protocol/transactions/transaction-results/index.md) **`tesSUCCESS`** el cual indica los cambios solicitados para aplicar en el ledger. Las transacciones fallidas en el ledger tienen el código de resultado de clase **`tec`**.1
Todas las transacciones incluidas en un ledger destruyen algo de XRP como un [coste de transacción](../transactions/transaction-cost.md), sin importar si tenían un código **`tes`** o **`tec`**. La cantidad exacta de XRP destruido es definido por las instrucciones de transacción firmadas.
@@ -59,13 +59,13 @@ Hay otras clases de códigos de resultado además de **`tes`** y **`tec`**. Cual
Cuando se trabaja con [APIs del XRP Ledger](../../references/http-websocket-apis/index.md), las aplicaciones deben distinguir entre transacciones candidatas propuestas para la inclusión en un ledger y transacciones validadas que están incluidas en un ledger. Solo los resultados de transacciones encontrados en un ledger validado son inmutables. Una transacción candidata puede eventualmente estar incluida en un leger validado, o puede que no.
-Importante: Algunas [APIs `rippled`](../../references/http-websocket-apis/index.md) proporcionan resultados provisionales, basados en transacciones candidatas 2. Las aplicaciones nunca deben basarse en resultados provisionales para determinar el resultado final de una transacción. La única forma de conocer si finalmente una transacción se ha realizado correctamente, es comprobar el estado de la transacción hasta que esté en un ledger validado y además tenga el código de resultado `tesSUCCESS`. Si la transacción está en un ledger validado con otro código de resultado, ha fallado. Si el ledger especificado en [`LastLedgerSequence`](../../references/protocol/transactions/common-fields.md) en una transacción ha sido validado, pero la transacción no aparece en ese ledger o en alguno anterior, entonces esa transacción ha fallado y nunca aparecerá en ningún ledger. Un resultado es definitivo solo para transacciones en un ledger validado o nunca podrán aparecer por las restricciones de `LastLedgerSequence` explicadas más adelante en este documento.
+Importante: Algunas [APIs `rippled`](../../references/http-websocket-apis/index.md) proporcionan resultados provisionales, basados en transacciones candidatas 2. Las aplicaciones nunca deben basarse en resultados provisionales para determinar el resultado final de una transacción. La única forma de conocer si finalmente una transacción se ha realizado correctamente, es comprobar el estado de la transacción hasta que esté en un ledger validado y además tenga el código de resultado `tesSUCCESS`. Si la transacción está en un ledger validado con otro código de resultado, ha fallado. Si el ledger especificado en [`LastLedgerSequence`](../../references/protocol/transactions/common-fields.md) en una transacción ha sido validado, pero la transacción no aparece en ese ledger o en alguno anterior, entonces esa transacción ha fallado y nunca aparecerá en ningún ledger. Un resultado es definitivo solo para transacciones en un ledger validado o nunca podrán aparecer por las restricciones de `LastLedgerSequence` explicadas más adelante en este documento.
## El protocolo XRP Ledger – Consenso y validación
La red peer-to-peer XRP Ledger consiste en muchos servidores independientes XRP Ledger (normalmente ejecutando [`rippled`](../networks-and-servers/index.md)) que aceptan y procesan transacciones. Las aplicaciones cliente firman y envían transacciones a servidores XRP Ledger, que transmiten estas transacciones candidatas a través de la red de procesamiento. Ejemplos de aplicaciones cliente incluyen carteras web y móvil, conexiones con instituciones financieras, y plataformas de trading electrónicas.
-[{% inline-svg file="/docs/img/xrp-ledger-network.svg" /%}](/docs/img/xrp-ledger-network.svg "Figura 4: Participantes en el Protocolo XRP Ledger")
+[{% inline-svg file="/docs/img/xrp-ledger-network.svg" /%}](/docs/img/xrp-ledger-network.svg 'Figura 4: Participantes en el Protocolo XRP Ledger')
_Figura 4: Participantes en el Protocolo XRP Ledger_
@@ -79,7 +79,7 @@ Los servidores de la red comparten información sobre transacciones candidatas.
Durante el consenso, cada servidor evalúa propuestas de un específico grupo de servidores, conocidos como validadores confiables por ese servidor, o _Unique Node List (UNL)_.5 Los validadores confiables representan un subconjunto de la red la cual, en conjunto, es "confiable" para no confabular en un intento de defraudar al servidor que evalúa las propuestas. Esta definición de "confianza" no requiere que se confie en cada validador individual elegido. Más bien, los validadores son elegidos en base a la expectativa de que no confabularán en un esfuerzo coordinado para falsificar los datos transmitidos en la red 6.
-[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg "Figura 5: Los validadores proponen y revisar conjuntos de transacciones")
+[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg 'Figura 5: Los validadores proponen y revisar conjuntos de transacciones')
_Figura 5: Validadores proponen y revisan conjuntos de transacciones — Al comienzo del consenso, los validadores pueden tener un conjunto distinto de transacciones. En siguientes rondas, los servidores modificarán sus propuestas para coincidir con las propuestas de sus validadores confiables. Este proceso determina qué transacciones deberían aplicar a la versión del ledger que se está actualmente debatiendo, y cuales deberían posponerse para próximas versiones del ledger._
@@ -98,7 +98,6 @@ La validación puede dividirse en aproximadamente dos partes:
Cada servidor en la red realiza una validación separada y local.
-
#### Calcular y compartir validaciones
Cuando el proceso de consenso se completa, cada servidor independientemente computa un nuevo ledger a partir del conjunto de transacciones acordado. Cada servidor calcula los resultados siguiendo las mismas reglas, las cuales pueden ser resumidas de la siguiente manera:
@@ -107,21 +106,21 @@ Cuando el proceso de consenso se completa, cada servidor independientemente comp
2. Colocar el conjunto de transacciones acordado en _orden canónico_ para que cada servidor la procese de la misma forma.
- [Orden canónico](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36) no es el orden de cómo las transacciones fueron recibidas, porque los servidores pueden recibir las mismas transacciones en diferente orden. Para prevenir a los participantes de competir sobre el orden de las trnasacciones, el orden canónico es difícil de manipular.
+ [Orden canónico](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36) no es el orden de cómo las transacciones fueron recibidas, porque los servidores pueden recibir las mismas transacciones en diferente orden. Para prevenir a los participantes de competir sobre el orden de las trnasacciones, el orden canónico es difícil de manipular.
3. Procesar cada transacción según sus instrucciones, en orden. Actualizar el estado del dato del ledger en consecuencia.
- Si la transacción no puede ser ejecutada exitósamente, incluye la transacción con un [código de resultado de clase `tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).1
+ Si la transacción no puede ser ejecutada exitósamente, incluye la transacción con un [código de resultado de clase `tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).1
- Para ciertos fallos de transacciones "recuperables", se mueve la transacción al final del orden canónico para volver a intentarla después de que se hayan ejecutado otras transacciones del mismo ledger.
+ Para ciertos fallos de transacciones "recuperables", se mueve la transacción al final del orden canónico para volver a intentarla después de que se hayan ejecutado otras transacciones del mismo ledger.
4. Actualizar la cabecera del ledger con el apropiado metadata.
- Esto incluye datos tales como el ledger index o índice del ledger, el hash identificativo del ledger previo validado (el "padre" de este), la hora de cierre aproximada de esta versión del ledger, y los hashes criptográficos de los contenidos de este ledger.
+ Esto incluye datos tales como el ledger index o índice del ledger, el hash identificativo del ledger previo validado (el "padre" de este), la hora de cierre aproximada de esta versión del ledger, y los hashes criptográficos de los contenidos de este ledger.
5. Calcular el hash identificativo de la nueva versión del ledger.
-[{% inline-svg file="/docs/img/consensus-calculate-validation.svg" /%}](/docs/img/consensus-calculate-validation.svg "Figura 7: Un servidor XRP Ledger calcula la validación de un ledger")
+[{% inline-svg file="/docs/img/consensus-calculate-validation.svg" /%}](/docs/img/consensus-calculate-validation.svg 'Figura 7: Un servidor XRP Ledger calcula la validación de un ledger')
_Figura 7: Un servidor XRP Ledger calcula la validación de un ledger — Cada servidor aplica transacciones acordadas por el anterior ledger validado. Los validadores envían sus resultados a toda la red._
@@ -129,7 +128,7 @@ _Figura 7: Un servidor XRP Ledger calcula la validación de un ledger — Cada s
Cada validador transmite sus resultados en forma de un mensaje firmado que contiene el hash de la versión de ledger calculada. Estos mensajes, llamados _validaciones_, permiten a cada servidor comparar el ledger que calculó con el de sus pares.
-[{% inline-svg file="/docs/img/consensus-declare-validation.svg" /%}](/docs/img/consensus-declare-validation.svg "Figura 8: El ledger es validado cuando la supermayoría de pares calcula el mismo resultado")
+[{% inline-svg file="/docs/img/consensus-declare-validation.svg" /%}](/docs/img/consensus-declare-validation.svg 'Figura 8: El ledger es validado cuando la supermayoría de pares calcula el mismo resultado')
_Figura 8: El ledger es validado cuando la supermayoría de pares calcula el mismo resultado - Cada servidor compara su su ledger calculado con los hashes recibidos de sus validadores elegidos. Si no hay acuerdo, el servidor debe recaluclar o recuperar el ledger correcto._
@@ -141,7 +140,6 @@ Si la red no logra un acuerdo de supermayoría sobre las validaciones, esto impl
Una vez que alcanzan supermayoría en el acuerdo de las validaciones, los servidores trabajan con el nuevo ledger validado, ledger index N+1. El consenso y el proceso de validación se repite 9, considerando transacciones candidatas que no fueron incluidas en la última ronda junto con nuevas transacciones presentadas mientras tanto.
-
## Conclusiones claves
Las transacciones enviadas al XRP Ledger no son procesadas inmediatamente. Durante un periodo de tiempo, cada transacciones permanece como candidata.
@@ -150,12 +148,12 @@ El ciclo de vida de una sola transacción es el siguiente:
- Una transacción es creada y firmada por un dueño de una cuenta.
- La transacción es enviada a la red.
- - Transacciones mal formadas podrán ser rechazadas inmediatamente.
- - Transacciones bien formadas pueden ser provisionalmente exitosas, y luego fallar.
- - Transacciones bien formadas pueden provisionalmente fallar, y luego fallar.
+ - Transacciones mal formadas podrán ser rechazadas inmediatamente.
+ - Transacciones bien formadas pueden ser provisionalmente exitosas, y luego fallar.
+ - Transacciones bien formadas pueden provisionalmente fallar, y luego fallar.
- Durante el consenso, la transacción es incluida en el ledger.
- - El resultado de un consenso exitoso es un ledger validado.
- - Si una ronda de consenso falla, el proceso de consenso se repita hasta que es exitoso.
+ - El resultado de un consenso exitoso es un ledger validado.
+ - Si una ronda de consenso falla, el proceso de consenso se repita hasta que es exitoso.
- El ledger validado incluye la transacción y esta afecta al estado del ledger.
Las aplicaciones deben solo confiar en información de ledgers validados, no en resultados provisionales de transacciones candidatas. Algunas [APIs de `rippled`](../../references/http-websocket-apis/index.md) devuelven inicialmente unos resultados provisionales para las transacciones. Los resultados de una transacción se convierten en inmutables solo si la transacción es incluida en un ledger validado, o la transacción incluye `LastLedgerSequence` y no aparece en ningún ledger validado con ese ledger index o menor.
@@ -164,31 +162,27 @@ Buenas prácticas para aplicaciones enviando transsacciones incluyen:
- Utilizar el parámetro `LastLedgerSequence` para asegurar que las transacciones se validen o fallen de forma determinista y rápida.
- Comprobar los resultados de transacciones en ledgers validados.
- - Hasta que el ledger que contiene la transacción es validado, o haya pasado `LastLedgerSequence`, los resultados son provisionales.
- - Transacciones con el código resultado **`tesSUCCESS`** y `"validated": true` se han realizado correctamente de forma inmutable.
- - Transacciones con otro código resultado y `"validated": true` han fallado de forma inmutable.
- - Transacciones que no aparecen en ningún ledger validado, incluido el ledger validado identificado por el `LastLedgerSequence` de la transacción ha fallado de forma inmutable.
- - Tener cuidado de usar un servidor con un histórico de ledger continuo para detectar este caso 10.
- - Puede ser necesario comprobar el estado de una transacción repetidamente hasta que el identificado por `LastLedgerSequence` es validado.
+ - Hasta que el ledger que contiene la transacción es validado, o haya pasado `LastLedgerSequence`, los resultados son provisionales.
+ - Transacciones con el código resultado **`tesSUCCESS`** y `"validated": true` se han realizado correctamente de forma inmutable.
+ - Transacciones con otro código resultado y `"validated": true` han fallado de forma inmutable.
+ - Transacciones que no aparecen en ningún ledger validado, incluido el ledger validado identificado por el `LastLedgerSequence` de la transacción ha fallado de forma inmutable.
+ - Tener cuidado de usar un servidor con un histórico de ledger continuo para detectar este caso 10.
+ - Puede ser necesario comprobar el estado de una transacción repetidamente hasta que el identificado por `LastLedgerSequence` es validado.
## Ver también
- **Conceptos:**
- - [Investigación del consenso](consensus-research.md)
- - [El mecanismo del consenso (YouTube)](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
+ - [Investigación del consenso](consensus-research.md)
+ - [El mecanismo del consenso (YouTube)](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
- **Tutoriales:**
- - [Envío de transacciones de forma correcta](../transactions/reliable-transaction-submission.md)
- - [Ejecutar `rippled` como un validator](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+ - [Envío de transacciones de forma correcta](../transactions/reliable-transaction-submission.md)
+ - [Ejecutar `rippled` como un validator](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
- **Referencias:**
- - [Referencia del fromato del ledger](../../references/protocol/ledger-data/index.md)
- - [Referencia del formato de la transacción](../../references/protocol/transactions/index.md)
- - [método consensus_info][]
- - [método validator_list_sites][]
- - [método validators][]
-
-
-
-
+ - [Referencia del fromato del ledger](../../references/protocol/ledger-data/index.md)
+ - [Referencia del formato de la transacción](../../references/protocol/transactions/index.md)
+ - [método consensus_info][]
+ - [método validator_list_sites][]
+ - [método validators][]
## Pies de notas
@@ -202,7 +196,7 @@ Buenas prácticas para aplicaciones enviando transsacciones incluyen:
5 – Cada servidor define su propios validadores confiables, pero la consistencia de la red depende en diferentes servidores eligiendo listas que tienen un mayor grado de superposición. Por esta razón, Ripple publica una lista de validadores recomendados.
-6 – Si las propuestas de todos los validadores fueron evaluadas, en lugar de exclusivamente por los validadores elegidos para no confabular, un atacante malicioso podría ejecutar más validadores para ganar poder desproporcionado sobre el proceso de validación, así podrían introducir transacciones inválidas u omitir transacciones válidas de las propuestas. La lista de validadores elegida [defiende de ataques Sybil](consensus-protections.md#ataques-sybil).
+6 – Si las propuestas de todos los validadores fueron evaluadas, en lugar de exclusivamente por los validadores elegidos para no confabular, un atacante malicioso podría ejecutar más validadores para ganar poder desproporcionado sobre el proceso de validación, así podrían introducir transacciones inválidas u omitir transacciones válidas de las propuestas. La lista de validadores elegida [defiende de ataques Sybil](consensus-protections.md#ataques-sybil).
7 – El umbral de supermayoría, a partir de noviembre del 2014, requiere que al menos el 80% de pares deben estar de acuerdo en un ledger para ser validado. Est el mismo porcentaje necesario para una ronda de consenso. Ambos umbrales están sujetos a cambio y no necesitan ser iguales.
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md b/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
index faab408406..0a5c5a1071 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
@@ -2,11 +2,12 @@
html: fee-voting.html
parent: consensus.html
seo:
- description: Cómo los validadores votan las comisiones o fees (coste de transacción y requisitos de reserva).
+ description: Cómo los validadores votan las comisiones o fees (coste de transacción y requisitos de reserva).
labels:
- Fees
- XRP
---
+
# Votación de comisiones o fees
Los validadores pueden votar por cambiar los [costes de transacción](../transactions/transaction-cost.md) básicos como los [requisitos de reserva](../accounts/reserves.md). Si las preferencias en la configuración de un validador son diferentes a los ajustes actuales de la red, el validador expresa sus preferencias a la red periódicamente. Si un cuórum de validadores está de acuerdo en un cambio, pueden aplicar un cambio que se haga efectivo a partir de entonces. Los validadores pueden hacer esto por varias razones, especialmente para adaptarse a cambios en el valor de XRP a largo plazo.
@@ -17,53 +18,52 @@ Los operadores de [validadores `rippled`](../../infrastructure/configuration/ser
Los parámetros que puedes configurar son los siguientes:
-| Parámetro | Descripción | Valor recomendado |
-|-----------|-------------|-------------------|
-| `reference_fee` | Cantidad de XRP, en _drops_ (1 XRP = 1 millón de drops.), que debe ser destruido para enviar la transacción de referencia, la transacción más barata posible. El coste de una transacción real es un múltiplo de ese valor, escalado dinámicamente basado en la carga de de los servidores individuales. | `10` (0.00001 XRP) |
-| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger. | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
-| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |
+| Parámetro | Descripción | Valor recomendado |
+| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
+| `reference_fee` | Cantidad de XRP, en _drops_ (1 XRP = 1 millón de drops.), que debe ser destruido para enviar la transacción de referencia, la transacción más barata posible. El coste de una transacción real es un múltiplo de ese valor, escalado dinámicamente basado en la carga de de los servidores individuales. | `10` (0.00001 XRP) |
+| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger. | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
+| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |
## Proceso de votación
-Cada 256º ledger se denomina un "flag" ledger. (Un flag ledger se define de manera que el `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` es igual a `0`.) En el ledger inmediatamente antes del flag ledger, cada validador cuyas preferencias de reserva de cuenta o coste de transacción son diferentes a la configuración actual de la red distribuye un mensaje de "voto" junto con su validación del ledger, indicando los valores que prefiere ese validador.
+Cada 256º ledger se denomina un "flag" ledger. (Un flag ledger se define de manera que el `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` es igual a `0`.) En el ledger inmediatamente antes del flag ledger, cada validador cuyas preferencias de reserva de cuenta o coste de transacción son diferentes a la configuración actual de la red distribuye un mensaje de "voto" junto con su validación del ledger, indicando los valores que prefiere ese validador.
En el propio flag ledger en sí, no ocurre nada, pero los validadores reciben y toman nota de los votos de los otros validadores en los que confían.
-Después de contar los votos de otros validadores, cada validador intenta llegar a un acuerdo entre sus propias preferencias y las preferencias de la mayoría de validadores en los que confía. (Por ejemplo, si un validador quiere aumentar el coste de transacción mínima de 10 a 100, pero la mayoría de los validadores solo quiere aumentarla de 10 a 20, el validador decide aumentar el coste de transacción a 20. Sin embargo, el validador nunca estará de acuerdo en un valor menor a 10 o superior a 100.) Si es posible llegar a un compromiso, el validador inserta una [pseudo transacción SetFee](../../references/protocol/transactions/pseudo-transaction-types/setfee.md) en su propuesta para el ledger siguiente al flag ledger. Otros validaodres que quieran el mismo cambio, insertan la misma pseudo-transacción SetFee en sus propuestas para el mismo ledger. (Los validadores cuyas preferencias coincidan con las existentes en la red no hacen nada.) Si una pseudo-transacción SetFee sobrevive al proceso de consenso para ser incluida en un ledger validado, entonces el nuevo coste de transacción y configuración de reservas indicados por la pseudo transacción SetFee toman efecto empezando por el siguiente ledger.
+Después de contar los votos de otros validadores, cada validador intenta llegar a un acuerdo entre sus propias preferencias y las preferencias de la mayoría de validadores en los que confía. (Por ejemplo, si un validador quiere aumentar el coste de transacción mínima de 10 a 100, pero la mayoría de los validadores solo quiere aumentarla de 10 a 20, el validador decide aumentar el coste de transacción a 20. Sin embargo, el validador nunca estará de acuerdo en un valor menor a 10 o superior a 100.) Si es posible llegar a un compromiso, el validador inserta una [pseudo transacción SetFee](../../references/protocol/transactions/pseudo-transaction-types/setfee.md) en su propuesta para el ledger siguiente al flag ledger. Otros validaodres que quieran el mismo cambio, insertan la misma pseudo-transacción SetFee en sus propuestas para el mismo ledger. (Los validadores cuyas preferencias coincidan con las existentes en la red no hacen nada.) Si una pseudo-transacción SetFee sobrevive al proceso de consenso para ser incluida en un ledger validado, entonces el nuevo coste de transacción y configuración de reservas indicados por la pseudo transacción SetFee toman efecto empezando por el siguiente ledger.
En resumen:
-* **Flag ledger -1**: Los validadores emiten sus votos.
-* **Flag ledger**: Los validadores cuentan sus votos y deciden qué SetFee incluir, si hay alguna.
-* **Flag ledger +1**: Los validadores incluyen una pseudo-transacción SetFee pseudo-transaction en sus ledgers propuestos.
-* **Flag ledger +2**: La nueva configuración toma efecto, si la pseudo-transacción alcanza consenso.
+- **Flag ledger -1**: Los validadores emiten sus votos.
+- **Flag ledger**: Los validadores cuentan sus votos y deciden qué SetFee incluir, si hay alguna.
+- **Flag ledger +1**: Los validadores incluyen una pseudo-transacción SetFee pseudo-transaction en sus ledgers propuestos.
+- **Flag ledger +2**: La nueva configuración toma efecto, si la pseudo-transacción alcanza consenso.
## Valores máximos de comisiones o fees
Los valores máximos posibles para las comisiones están limitadas por los tipos de datos internos almacenados en el [objeto de ledger FeeSettings](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md). Los valores son los siguientes:
-| Parámetro | Valor máximo (drops) | Valor máximo (XRP)
-|-----------|-----------------------|----|
-| `reference_fee` | 264 | (Más XRP del que nunca ha existido.) |
-| `account_reserve` | 232 drops | Aproximadamente 4294 XRP |
-| `owner_reserve` | 232 drops | Aproximadamente 4294 XRP |
-
+| Parámetro | Valor máximo (drops) | Valor máximo (XRP) |
+| ----------------- | -------------------- | ------------------------------------ |
+| `reference_fee` | 264 | (Más XRP del que nunca ha existido.) |
+| `account_reserve` | 232 drops | Aproximadamente 4294 XRP |
+| `owner_reserve` | 232 drops | Aproximadamente 4294 XRP |
## Ver también
- **Conceptos:**
- - [Enmiendas](../networks-and-servers/amendments.md)
- - [Coste de transacción](../transactions/transaction-cost.md)
- - [Reservas](../accounts/reserves.md)
- - [Cola de transacción](../transactions/transaction-queue.md)
+ - [Enmiendas](../networks-and-servers/amendments.md)
+ - [Coste de transacción](../transactions/transaction-cost.md)
+ - [Reservas](../accounts/reserves.md)
+ - [Cola de transacción](../transactions/transaction-queue.md)
- **Tutoriales:**
- - [Configurar `rippled`](../../infrastructure/configuration/index.md)
+ - [Configurar `rippled`](../../infrastructure/configuration/index.md)
- **Referencias:**
- - [Método fee][]
- - [Método server_info][]
- - [Objeto FeeSettings](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
- - [Pseudo-transacción SetFee][]
+ - [Método fee][]
+ - [Método server_info][]
+ - [Objeto FeeSettings](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
+ - [Pseudo-transacción SetFee][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/index.md b/@l10n/es-ES/docs/concepts/consensus-protocol/index.md
index 567a85925f..044f3e76e5 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/index.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/index.md
@@ -2,18 +2,18 @@
html: consensus.html
parent: concepts.html
seo:
- description: El consenso es cómo los nuevos bloques de transacciones son confirmados por la blockchain XRP Ledger.
+ description: El consenso es cómo los nuevos bloques de transacciones son confirmados por la blockchain XRP Ledger.
labels:
- Blockchain
top_nav_grouping: Popular Pages
---
+
# El protocolo de consenso
Este tema explica cómo el XRP Ledger descentralizado confirma nuevas transacciones y nuevas versiones de ledgers, creando una blockchain.
El consenso es la propiedad más importante de cualquier sistema de pagos descentralizado. En sistemas de pagos centralizados tradicionales, un administrador autorizado tiene la última palabra en cómo los pagos deben ocurrir. En sistemas descentralizados, por definición, no hay un administrador para hacerlo. En cambio, los sistemas descentralizados como el XRP Ledger definen un conjunto de reglas que todos los participantes siguen, así cada participante puede estar de acuerdo en la misma exacta serie de eventos y sus resultados en cualquier momento. A este conjunto de reglas les llamamos un _protocolo de consenso_.
-
## Propiedades del protocolo de consenso
El XRP Ledger utiliza el protocolo de consenso de una forma diferente a todos los activos digitales anteriores. Este protocolo, conocido como el Protocolo de Consenso de XRP Ledger, está diseñado para tener las siguientes propiedades importantes:
@@ -32,7 +32,6 @@ Este protocolo sigue evolucionando, al igual que nuestro conocimiento de sus lí
Los protocolos de consenso son una solución al _problema del doble gasto_: el desafío de prevenir a alguien de gastar con éxito dos veces el mismo dinero digital. La parte más dificil de este problema es poner las transacciones en orden: sin una autoridad central, puede ser dificil resolver disputas sobre qué transacciones van primero cuando dos o más transacciones mutuamente excluyentes se envían al mismo tiempo. Para un análisis del problema del doble gasto, cómo el Protocolo de Consenso XRP Ledger resuelve este problema, las concesiones y limitaciones involucradas, ver [Principios y reglas del consenso](consensus-principles-and-rules.md).
-
## Histórico del ledger
El XRP Ledger procesa transacciones en bloques llamadados "versiones del ledger", o "ledgers" abreviado. Cada versión del ledger contiene tres partes:
@@ -41,27 +40,25 @@ El XRP Ledger procesa transacciones en bloques llamadados "versiones del ledger"
- El conjunto de transacciones que han sido aplicadas en el ledger anterior para dar como resultado este.
- Metadatos sobre la versión actual del ledger, como el índice del ledger, un [hash criptográfico](https://en.wikipedia.org/wiki/Cryptographic_hash_function) que identifica de forma única su contenido, e información sobre el ledger parental que se usó como base para construir este.
-[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "Figura 1: Anatomía de una versión de un ledger, que incluye transacciones, estado, y metadatos")
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg 'Figura 1: Anatomía de una versión de un ledger, que incluye transacciones, estado, y metadatos')
Cada versión del ledger está numerado por un _ledger index_ o índice ledger y se basa en una versión anterior del ledger cuyo índice es uno menos, y se remonta hasta el punto de partida llamado el _ledger génesis_ con un índice ledger 1.[¹](#footnote-1) Como Bitcoin y otras tecnologías blockchain, esto forma el histórico público de todas las transacciones y sus resultados. A diferencia de otras tecnologías blockchain, cada nuevo "bloque" en el XRP Ledger contiene la totalidad del estado actual, por lo que no tienes que recopilar toda el histórico completo para conocer qué esta pasando ahora.[²](#footnote-2)
El objetivo principal del Protocolo de Consenso del XRP Ledger es acordar un conjunto de transacciones para añadir la nueva siguiente versión del ledger, aplicarlos en un orden bien definido, y después confirmar con todo el mundo para tener los mismos resultados. Cuando esto ocurre satisfactoriamente, una versión del ledger es considerado _validado_, y definitivo. A partir de aquí, el proceso continua construyendo la siguiente versión del ledger.
-
## Validación basada en la confianza
El principio básico detrás del mecanismo de consenso del XRP Ledger es que un poco de confianza ayuda mucho. Cada participante en la red elige un conjunto de _validadores_, servidores [configurados específicamente para participar activamente en el consenso](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md), gestionados por diferentes equipos que se espera que se comporten honestamente la mayor parte del tiempo según el protocolo. Aún más importante, el conjunto de validadores elegidos no deberían confabular entre sí para infringir las reglas de la misma manera. Esta lista se llama _Lísta Única de Nodos_, o UNL.
A medida que la red avanza, cada servidor escucha a sus validadores de confianza[³](#footnote-3); siempre y cuando un porcentaje lo suficientemente grande de ellos esté de acuerdo en que un conjunto de transacciones debería ocurrir y que un ledger dado es el resultado, el servidor declara un consenso. Si no están de acuerdo, los validadores modifican sus propuestas para que coincidan más con las de otros validadores en los que confían, repitiendo el proceso en varias rondas hasta alcanzar un consenso.
-[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg "Figura 2: Rondas de consenso. Los validadores revisan sus propuestas para coincidir con otros validadores en los que confían")
+[{% inline-svg file="/docs/img/consensus-rounds.svg" /%}](/docs/img/consensus-rounds.svg 'Figura 2: Rondas de consenso. Los validadores revisan sus propuestas para coincidir con otros validadores en los que confían')
-Esta bien si una pequeña porción de los validadores no funciona correctamente todo el tiempo. Siempre que menos del 20% de los validadores de confianza fallen, el consenso puede continuar sin impedimentos; y confirman una transacción inválida requeriría que más del 80% de los validadodres de confianza se confabulasen. Si más del 20% o menos del 80% de los validadores confiables fallan, la red para de progresar.
+Esta bien si una pequeña porción de los validadores no funciona correctamente todo el tiempo. Siempre que menos del 20% de los validadores de confianza fallen, el consenso puede continuar sin impedimentos; y confirman una transacción inválida requeriría que más del 80% de los validadodres de confianza se confabulasen. Si más del 20% o menos del 80% de los validadores confiables fallan, la red para de progresar.
Para una exploración de cómo el Protocolo de Consenso del XRP Ledger responde a varios desafíos, ataques, y casos de fallo, ver [Protecciones del Consenso contra Ataques y Modos de Fallo](consensus-protections.md).
-
-----
+---
## Pies de página
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md b/@l10n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md
index 774991aade..1ca9de2388 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md
@@ -2,11 +2,12 @@
html: invariant-checking.html
parent: consensus.html
seo:
- description: Entender qué es la verificación invariantes, por qué existe, cómo funciona, y qué comprobaciones de invariantes están activas.
+ description: Entender qué es la verificación invariantes, por qué existe, cómo funciona, y qué comprobaciones de invariantes están activas.
labels:
- Blockchain
- Seguridad
---
+
# Comprobación de invariantes
La comprobación de invariantes es una característica de seguridad del XRP Ledger. Consiste en un conjunto de comprobaciones, separadas del procesamiento normal de transacciones, que garantiza que ciertas _invariantes_ se mantienen ciertas en todas las transacciones.
@@ -15,7 +16,6 @@ Como muchas características de seguridad, todos esperamos que la comprobación
Las invariantes no deberían activarse, pero aseguran la integridad del XRP Ledger contra errores aún por descubrir o incluso creados.
-
## Por qué existe
- El código fuente del XRP Ledger es complejo y extenso; hay un potencial alto de que el código se ejecute incorrectamente.
@@ -25,15 +25,12 @@ Específicamente, la ejecución de transacciones incorrectas podría crear datos
El procesamiento de transacciones incorrectas socavaría el valor de confianza en el XRP Ledger. Las comprobación de invariantes proporciona valor a todo el XRP Ledger porque agrega la característica de confiabilidad.
-
-
## Cómo funciona
El comprobador de invariantes es una segunda capa de código que se ejecuta automáticamente en tiempo real después de cada transacción. Antes de que los resultados de la transacción se confirmen en el ledger, el comprobador de invariantes examina esos cambios en busca de corrección. Si los resultados de la transacción rompieran una de las reglas estrictas del XRP Ledger, el comprobador de invariantes rechazará la transacción. Las transacciones que son rechazadas de esta manera tienen el código de resultado `tecINVARIANT_FAILED` y se incluyen en el ledger sin efectos.
Para incluir la transacción en el ledger con un código de clase `tec`, es necesario realizar algún procesamiento mínimo. Si este procesamiento mínimo aún rompe un invariante, la transacción falla con el código `tefINVARIANT_FAILED` en su lugar, y no se incluye en el ledger en absoluto.
-
## Invariantes activas
El XRP Ledger comprueba todas las siguientes invariantes en cada transación:
@@ -74,99 +71,89 @@ El XRP Ledger comprueba todas las siguientes invariantes en cada transación:
- [Nueva Account Root válida](#nueva-account-root-válida)
-
### Comprobación de coste de transacción
- **Condicion(es) invariantes:**
- - La cantidad de [coste de transacción](../transactions/transaction-cost.md) nunca debe ser negativa, ni tampoco más grande que la especificada en el coste de la transacción.
-
+ - La cantidad de [coste de transacción](../transactions/transaction-cost.md) nunca debe ser negativa, ni tampoco más grande que la especificada en el coste de la transacción.
### XRP no creado
- **Condicion(es) invariantes:**
- - Una transacción no debe crear XRP y solo debería destruir el XRP del [coste de transacción](../transactions/transaction-cost.md).
-
+ - Una transacción no debe crear XRP y solo debería destruir el XRP del [coste de transacción](../transactions/transaction-cost.md).
### Account Roots no eliminadas
- **Condicion(es) invariantes:**
- - Una [cuenta](../accounts/index.md) no puede ser eliminada del ledger excepto por una [transacción AccountDelete][].
- - Una transacción AccountDelete exitosa siempre borra exactamente 1 cuenta.
-
+ - Una [cuenta](../accounts/index.md) no puede ser eliminada del ledger excepto por una [transacción AccountDelete][].
+ - Una transacción AccountDelete exitosa siempre borra exactamente 1 cuenta.
### Comprobaciones de balance XRP
- **Condicion(es) invariantes:**
- - El balance de XRP de una cuenta debe ser de tipo XRP, y no puede ser menor a 0 o más de 100 mil millones XRP exactamente.
-
+ - El balance de XRP de una cuenta debe ser de tipo XRP, y no puede ser menor a 0 o más de 100 mil millones XRP exactamente.
### Coincidencia de tipos de entrada de ledger
- **Condicion(es) invariantes:**
- - Las entradas de los ledgers modificados deberían coincidir en tipo y las entradas añadidas deben ser de un [tipo válido](../../references/protocol/ledger-data/ledger-entry-types/index.md).
-
+ - Las entradas de los ledgers modificados deberían coincidir en tipo y las entradas añadidas deben ser de un [tipo válido](../../references/protocol/ledger-data/ledger-entry-types/index.md).
### No XRP Trust Lines
- **Condicion(es) invariantes:**
- - [Trust lines](../tokens/fungible-tokens/index.md) o líneas de confianza utilizando XRP no están permitidas.
-
+ - [Trust lines](../tokens/fungible-tokens/index.md) o líneas de confianza utilizando XRP no están permitidas.
### No malas ofertas
- **Condicion(es) invariantes:**
- - Las [ofertas](../../references/protocol/ledger-data/ledger-entry-types/offer.md) deben ser de cantidades no negativas y no pueden ser de XRP para XRP.
-
+ - Las [ofertas](../../references/protocol/ledger-data/ledger-entry-types/offer.md) deben ser de cantidades no negativas y no pueden ser de XRP para XRP.
### No escrow cero
- **Condicion(es) invariantes:**
- - Una entrada [escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md) debe contener más de 0 XRP y menos que 100 mil millones de XRP.
-
+ - Una entrada [escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md) debe contener más de 0 XRP y menos que 100 mil millones de XRP.
### Nueva Account Root válida
- **Condicion(es) invariantes:**
- - Una nueva [account root](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) debe ser la consecuencia de un pago.
- - Una nueva account root debe tener la correcta [secuencia](../../references/protocol/data-types/basic-data-types.md#account-sequence) de inicio.
- - Una transacción no debe crear más de una nueva [cuenta](../accounts/index.md).
+ - Una nueva [account root](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) debe ser la consecuencia de un pago.
+ - Una nueva account root debe tener la correcta [secuencia](../../references/protocol/data-types/basic-data-types.md#account-sequence) de inicio.
+ - Una transacción no debe crear más de una nueva [cuenta](../accounts/index.md).
### ValidNFTokenPage
- **Condicion(es) invariantes:**
- - El número de NFTs acuñados o quemados solo puede ser cambiado por transacciones `NFTokenMint` o `NFTokenBurn`.
- - Una transacción NFTokenMint exitosa debe incrementar el número de NFTs.
- - Una transacción NFTokenMint fallida no puede cambiar el número de NFTs acuñados.
- - Una transacción NFTokenMint no puede cambiar el número de NFTs quemados.
- - Una transacción NFTokenBurn debe incrementar el número de NFTs quemados.
- - Una transacción NFTokenBurn no debe cambiar el número de NFTs quemados.
- - Una transacción NFTokenBurn no puede cambiar el número de NFTs acuñados.
+ - El número de NFTs acuñados o quemados solo puede ser cambiado por transacciones `NFTokenMint` o `NFTokenBurn`.
+ - Una transacción NFTokenMint exitosa debe incrementar el número de NFTs.
+ - Una transacción NFTokenMint fallida no puede cambiar el número de NFTs acuñados.
+ - Una transacción NFTokenMint no puede cambiar el número de NFTs quemados.
+ - Una transacción NFTokenBurn debe incrementar el número de NFTs quemados.
+ - Una transacción NFTokenBurn no debe cambiar el número de NFTs quemados.
+ - Una transacción NFTokenBurn no puede cambiar el número de NFTs acuñados.
### NFTokenCountTracking
- **Condicion(es) invariantes:**
- - La página está correctamente asociada al dueño.
- - La página está correctamente ordenada entre el siguiente y el anterior enlace.
- - La página contiene un número válido de NFTs.
- - Los NFTs en esta página no pertenecen a una página anterior o posterior.
- - Los NFTs están correctamente ordenados en la página.
- - Cada URI, si está presente, no está vacío.
+ - La página está correctamente asociada al dueño.
+ - La página está correctamente ordenada entre el siguiente y el anterior enlace.
+ - La página contiene un número válido de NFTs.
+ - Los NFTs en esta página no pertenecen a una página anterior o posterior.
+ - Los NFTs están correctamente ordenados en la página.
+ - Cada URI, si está presente, no está vacío.
## Ver también
- **Blog:**
- - [Protegiendo el ledger: Comprobación de invariantes](https://xrpl.org/blog/2017/invariant-checking.html)
+ - [Protegiendo el ledger: Comprobación de invariantes](https://xrpl.org/blog/2017/invariant-checking.html)
- **Repositorio:**
- - [Invariant Check.h](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
- - [Invariant Check.cpp](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
- - [Parámetros del sistema](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
- - [Cantidad XRP](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
- - [Formatos de ledger](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
-
+ - [Invariant Check.h](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
+ - [Invariant Check.cpp](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
+ - [Parámetros del sistema](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
+ - [Cantidad XRP](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
+ - [Formatos de ledger](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
- **Otros:**
- - [Trust Lines autorizadas](../tokens/fungible-tokens/authorized-trust-lines.md)
- - [Calculando cambios de balance para una transacción](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
+ - [Trust Lines autorizadas](../tokens/fungible-tokens/authorized-trust-lines.md)
+ - [Calculando cambios de balance para una transacción](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md b/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
index e079cbb81d..2a37309697 100644
--- a/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
@@ -2,10 +2,11 @@
html: negative-unl.html
parent: consensus.html
seo:
- description: Comprende cómo la UNL negativa mejora la resiliencia durante interrupciones parciales.
+ description: Comprende cómo la UNL negativa mejora la resiliencia durante interrupciones parciales.
labels:
- Blockchain
---
+
# UNL negativa
_Añadida por la [enmienda NegativeUNL](/resources/known-amendments.md#negativeunl)._
@@ -36,14 +37,12 @@ Si más del 20% de los validadores de repente se desconectan todos a la vez, los
La UNL negativa no tiene efecto sobre el modo solitario o [stand-alone mode](../networks-and-servers/rippled-server-modes.md) porque el servidor no utiliza el consenso en el modo solitario.
-
## Cómo funciona
La UNL negativa está estrechamente ligada al [proceso de consenso](index.md) y está diseñada con salvaguardas para mantener la continuidad y confiabilidad de la red en situaciones adversas. Cuando todos los validadores confiables están funcionando normalmente, la UNL negativa no se utiliza y no tiene efecto. Cuando algunos validadores parecen estar desconectados o desincronizados, se aplican las reglas de la UNL negativa.
La UNL negativa está diseñada intencionalmente para cambiar a una velocidad lenta, para evitar desacuerdos basados en el tiempo sobre qué la UNL negativa debería aplicarse al proceso de consenso de una versión dada del ledger.
-
### Medición de fiabilidad
Cada servidor en la red tiene una UNL, la lista de validadores en los que confía para no colisionar. (Por defecto, la UNL exacta de un servidor se configura implícitamente en función de la lista de validadores recomendada que Ripple publica). Cada servidor sigue la _fiabilidad_ de sus validadores de confianza utilizando una métrica única: el porcentaje de los últimos 256 ledgers donde el voto de validación del validador coincidió con la vista de consenso del servidor. En otras palabras:
@@ -64,8 +63,6 @@ Cada servidor, incluidos los validadores, calcula de forma independiente las pun
**Consejo:** Los validadores siguen su propia fiabilidad, pero no proponen agregarse a la UNL negativa. La medida de fiabilidad de un validador por sí sola no puede tener en cuenta cuán exitosamente se propagan sus votos de validación a través de la red, por lo que es menos confiable que las mediciones de servidores externos.
-
-
### Modificación de la UNL negativa
Una versión del ledger se considera un _flag ledger_ si su índice de ledger o index es divisible entera por 256. La UNL negativa solo se puede modificar en flag ledgers. (Los flag ledgers ocurren una vez cada 15 minutos en la red principal, Mainnet, de XRP Ledger. Pueden estar más separados en redes de prueba (test) que tienen un volumen de transacciones bajo).
@@ -74,32 +71,30 @@ En cada flag ledger, se aplican todos los siguientes cambios:
1. Los cambios la UNL negativa que se programaron en el flag ledger anterior entran en vigencia para la siguiente versión del ledger. El proceso de consenso para validar este flag ledger en sí mismo no utiliza el cambio programado.
- **Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/index.md).
+ **Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/index.md).
2. Si la UNL negativa no está llena, cada servidor propone añadir **hasta 1** validador a la UNL negativa entre sus validadores confiables con una fiabilidad inferior al 50%.
3. Si la UNL negativa no está vacía, cada servidor propone eliminar **hasta 1** validador de la UNL negativa. Un servidor puede proponer eliminar un validador de la UNL negativa por dos motivos:
- - Califica a ese validador con una fiabilidad > 80%.
- - No tiene a ese validador en su UNL. (Si un validador deja de funcionar permanentemente, esta regla garantiza que se elimine de la UNL negativa en el ledger después de que se haya eliminado de las UNL configuradas de los servidores).
+ - Califica a ese validador con una fiabilidad > 80%.
+ - No tiene a ese validador en su UNL. (Si un validador deja de funcionar permanentemente, esta regla garantiza que se elimine de la UNL negativa en el ledger después de que se haya eliminado de las UNL configuradas de los servidores).
4. Si un cambio propuesto a la UNL negativa logra un consenso, el cambio se programa para entrar en vigencia en el siguiente flag ledger. Se puede programar hasta una adición y una eliminación de esta manera.
Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/index.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.
Los cambios programados y efectivos de la UNL negativa se rastrean en el [objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md) en los datos de estado del ledger.
-
### Límites de la UNL negativa
Para prevenir que la red se fragmente en dos o más subredes, la UNL negativa no puede reducir el requisito de cuórum a menos del 60% de las entradas de UNL _totales_. Para hacer cumplir esto, un servidor considera que la UNL negativa está "llena" si el número de validadores en la UNL negativa es del 25% (redondeado hacia abajo) del número de validadores en la UNL configurada del servidor. (El 25% se basa en el cálculo de que si se eliminan el 25% de los validadores, un consenso del 80% del 75% restante equivale al 60% del número original). Si un servidor considera que la UNL negativa está llena, no propondrá nuevas adiciones a la UNL negativa; pero, como siempre, el resultado final depende de lo que haga un consenso de validadores de confianza.
-
### Elección de múltiples validadores candidatos
Es posible que múltiples validadores sean candidatos para ser agregados a la UNL negativa, según el umbral de fiabilidad. Dado que como máximo se puede agregar un validador a la UNL negativa a la vez, los servidores deben elegir qué validador proponer agregar. Si hay múltiples candidatos, el servidor elige cuál proponer con el siguiente mecanismo:
1. Comienza con el hash del ledger de la versión anterior.
-0. Toma la clave pública de cada validador candidato.
-0. Cacula el valor de exclusión-o (XOR) del validador candidato y el hash del ledger padre.
-0. Propón el validador con el resultado numéricamente más bajo de la operación XOR.
+2. Toma la clave pública de cada validador candidato.
+3. Cacula el valor de exclusión-o (XOR) del validador candidato y el hash del ledger padre.
+4. Propón el validador con el resultado numéricamente más bajo de la operación XOR.
Si hay múltiples candidatos para ser eliminados de la UNL negativa en un flag ledger dado, los servidores utilizan el mismo mecanismo para elegir entre ellos.
@@ -109,7 +104,6 @@ Este mecanismo tiene varias propiedades útiles:
- La mayoría de los servidores eligen el mismo candidato incluso si calculan puntuaciones ligeramente diferentes para sus validadores de confianza. Esto se mantiene incluso si esos servidores discrepan sobre qué validador es _menos_ o _más_ confiable. Esto incluso se mantiene en muchos casos en los que los servidores discrepan sobre si algunos validadores están por encima o por debajo de los umbrales de fiabilidad. Por lo tanto, es probable que la red llegue a un consenso sobre qué validador agregar o eliminar.
- No siempre da los mismos resultados en cada versión del ledger. Si un cambio propuesto a la UNL negativa no logra un consenso, la red no queda atrapada con algunos servidores intentando y fallando en agregar o eliminar ese validador cada vez. La red puede intentar agregar o eliminar un candidato diferente de la UNL negativa en un flag ledger posterior.
-
### Filtrado de validaciones
Durante [el paso de validación del proceso de consenso](consensus-structure.md#validation), se desactivan los validadores en la UNL negativa del ledger padre. Cada servidor calcula una "UNL efectiva" que consiste en su UNL configurada con los validadores desactivados eliminados, y recalcula su cuórum. (El cuórum siempre es al menos el 80% de la UNL efectiva y al menos el 60% de la UNL configurada). Si un validador desactivado envía votos de validación, los servidores siguen esos votos para fines de cálculo de la medida de fiabilidad del validador desactivado, pero no utilizan esos votos para determinar si una versión del ledger ha alcanzado un consenso.
@@ -124,55 +118,53 @@ El siguiente ejemplo demuestra cómo afecta la UNL negativa al proceso de consen
1. Supón que la UNL de tu servidor consta de 38 validadores de confianza, por lo que un cuórum del 80% es al menos 31 de 38 validadores.
-[{% inline-svg file="/docs/img/negative-unl-01.svg" /%}](/docs/img/negative-unl-01.svg "Diagrama: Caso normal: UNL negativa sin utilizar, el cuorum es 80% de los validadores configurados.")
+[{% inline-svg file="/docs/img/negative-unl-01.svg" /%}](/docs/img/negative-unl-01.svg 'Diagrama: Caso normal: UNL negativa sin utilizar, el cuorum es 80% de los validadores configurados.')
2. Imagina que 2 de esos validadores, llamados MissingA y UnsteadyB, parecen haberse desconectado. (Ambos tienen puntuaciones de fiabilidad < 50%.) Durante el proceso de consenso para el ledger _N_, muchos de los validadores restantes proponen agregar a UnsteadyB en la UNL negativa. La moción pasa mediante un cuórum de al menos 31 de los validadores restantes, y el ledger _N_ se valida con UnsteadyB programado para ser desactivado.
-[{% inline-svg file="/docs/img/negative-unl-02.svg" /%}](/docs/img/negative-unl-02.svg "Diagrama: UnsteadyB está programado para desactivarse.")
-
+[{% inline-svg file="/docs/img/negative-unl-02.svg" /%}](/docs/img/negative-unl-02.svg 'Diagrama: UnsteadyB está programado para desactivarse.')
3. Para ledgers desde _N+1_ hasta _N+256_, el proceso de consenso continua sin cambios.
4. En el siguiente flag ledger, ledger _N+256_, UnsteadyB se mueve automáticamente de "programado" a la lista "desconectados" en el ledger. Además, dado que MissingA está todavía offline, un consenso de validadores programa a MissingA para ser desactivado en el siguiente flag ledger.
-[{% inline-svg file="/docs/img/negative-unl-04.svg" /%}](/docs/img/negative-unl-04.svg "Diagrama: UnsteadyB se desactiva y MissingA es programado para ser desactivado, también.")
+[{% inline-svg file="/docs/img/negative-unl-04.svg" /%}](/docs/img/negative-unl-04.svg 'Diagrama: UnsteadyB se desactiva y MissingA es programado para ser desactivado, también.')
5. Para los ledgers _N+257_ a _N+512_, el cuorum es ahora 30 de 37 validadores.
6. UnsteadyB vuelve a estar online en el ledger _N+270_. Envía votos de validación que están de acuerdo con el resto de la red de los ledgers _N+270_ a _N+511_, dándole una puntuación de confiabilidad de > 80%.
-[{% inline-svg file="/docs/img/negative-unl-06.svg" /%}](/docs/img/negative-unl-06.svg "Diagrama: UnsteadyB vuelve a estar online, pero sigue desactivado.")
+[{% inline-svg file="/docs/img/negative-unl-06.svg" /%}](/docs/img/negative-unl-06.svg 'Diagrama: UnsteadyB vuelve a estar online, pero sigue desactivado.')
7. En el siguiente flag ledger, _N+256_, MissingA se mueve automáticamente a la lista de desactivados, como estaba programado. Mientras tanto, un consenso de validadores programa que UnsteadyB sea eliminado de la UNL negativa, debido a su mejora en la puntuación de confianza.
-[{% inline-svg file="/docs/img/negative-unl-07.svg" /%}](/docs/img/negative-unl-07.svg "Diagrama: MissingA está desactivado y UnsteadyB está programado para ser reactivado.")
+[{% inline-svg file="/docs/img/negative-unl-07.svg" /%}](/docs/img/negative-unl-07.svg 'Diagrama: MissingA está desactivado y UnsteadyB está programado para ser reactivado.')
8. Para los ledgers _N+513_ a _N+768_, el cuorum es 29 de 36 validadores. UnsteadyB continua enviando validaciones de manera estable mientras que MissingA continua offline.
9. En el flag ledger _N+768_, UnsteadyB es automáticamente eliminado de la lista de desactivados, como estaba programado.
-[{% inline-svg file="/docs/img/negative-unl-09.svg" /%}](/docs/img/negative-unl-09.svg "Diagrama: UnsteadyB es eliminado de la lista de desactivados.")
+[{% inline-svg file="/docs/img/negative-unl-09.svg" /%}](/docs/img/negative-unl-09.svg 'Diagrama: UnsteadyB es eliminado de la lista de desactivados.')
10. Eventualmente, tú decides que MissingA es probable que no vuelva, así que lo eliminas de tu UNL. Tu servidor empieza a proponer eliminando a MissingA de la UNL negativa en cada flag ledger posterior.
-[{% inline-svg file="/docs/img/negative-unl-10.svg" /%}](/docs/img/negative-unl-10.svg "Diagrama: Después de eliminar a MissingA de tu UNL, se propone eliminarlo de la UNL negativa también.")
+[{% inline-svg file="/docs/img/negative-unl-10.svg" /%}](/docs/img/negative-unl-10.svg 'Diagrama: Después de eliminar a MissingA de tu UNL, se propone eliminarlo de la UNL negativa también.')
11. A medida que los operadores de validadores eliminar a MissingA de sus UNLs, sus validadores también votan para eliminar MissingA de la UNL negativa. Cuando suficientes validadores lo han hecho, la propuesta de eliminar a MissingA consigue un consenso, y MissingA está programado para ser eliminado de la UNL negativa.
-[{% inline-svg file="/docs/img/negative-unl-11.svg" /%}](/docs/img/negative-unl-11.svg "Diagrama: MissingA es eliminado de la UNL negativa.")
-
+[{% inline-svg file="/docs/img/negative-unl-11.svg" /%}](/docs/img/negative-unl-11.svg 'Diagrama: MissingA es eliminado de la UNL negativa.')
## Ver también
- **Conceptos:**
- - [Protocolo de consenso](index.md)
+ - [Protocolo de consenso](index.md)
- **Tutoriales:**
- - [Conecta tu `rippled` a la red paralela](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
- - [Ejecuta `rippled` como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+ - [Conecta tu `rippled` a la red paralela](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
+ - [Ejecuta `rippled` como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
- **Referencias:**
- - [Objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
- - [Pseudo-transacción UNLModify][]
- - [método ledger_entry][]
- - [método consensus_info][]
+ - [Objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
+ - [Pseudo-transacción UNLModify][]
+ - [método ledger_entry][]
+ - [método consensus_info][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/ledgers/index.md b/@l10n/es-ES/docs/concepts/ledgers/index.md
index dd2c9c5783..53fbe49717 100644
--- a/@l10n/es-ES/docs/concepts/ledgers/index.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/index.md
@@ -2,16 +2,17 @@
html: ledgers.html
parent: concepts.html
seo:
- description: Los libros contables o ledgers son la estructura de datos que contiene datos en la red compartida de XRP Ledger. Una cadena de ledgers registra el historial de transacciones y cambios de estado.
+ description: Los libros contables o ledgers son la estructura de datos que contiene datos en la red compartida de XRP Ledger. Una cadena de ledgers registra el historial de transacciones y cambios de estado.
labels:
- Blockchain
- Retención de datos
---
+
# Ledgers
El XRP Ledger es un libro contable global compartido que está abierto para todos. Participantes individuales pueden confiar en la la integridad del ledger sin tener que confiar en una única institución para manejarlo. El protocolo XRP Ledger logra esto mediante la gestión de la base de datos de contabilidad que solo puede ser actualizada de acuerdo a unas reglas específicas. Cada servidor en la reed peer-to-peer guarda una copia completa de la base de datos del ledger o libro contable, y la red distribuye transacciones candidatas, las cuales se incluyen en bloques de acuerdo al [proceso de consenso](../consensus-protocol/index.md).
-[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg "Diagrama: Cada ledger es el resultado de aplicar transacciones a la anterior versión del ledger.")
+[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg 'Diagrama: Cada ledger es el resultado de aplicar transacciones a la anterior versión del ledger.')
El ledger global compartido consiste en una serie de bloques, llamadas versiones del ledger o simplemente _ledgers_. Cada versión del ledger tiene un índice o [Ledger Index][] el cual identifica el orden correcto de los ledgers. Cada ledger cerrado es permanente y también tiene un único valor hash que lo identifica.
@@ -19,13 +20,11 @@ En cualquier momento, cada servidor XRP Ledger tiene un ledger _abierto_ en prog
Una versión del ledger consta de varias partes:
-[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "Diagrama: Un ledger tiene transacciones, un arbol de estado, y una cabecera con la hora de cierre y la información de validación")
-
-* Una **cabecera** - El índice del ledger o [Ledger Index][], hashes de sus otros contenidos, y otros metadatos.
-* Un **arbol de transacciones** - Las [transacciones](../../references/protocol/transactions/index.md) que se aplicaron al ledger anterior para hacer este.
-* Un **arbol de estado** - Todos los datos en el ledger, como [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md): balances, configuraciones, y demás.
-
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg 'Diagrama: Un ledger tiene transacciones, un arbol de estado, y una cabecera con la hora de cierre y la información de validación')
+- Una **cabecera** - El índice del ledger o [Ledger Index][], hashes de sus otros contenidos, y otros metadatos.
+- Un **arbol de transacciones** - Las [transacciones](../../references/protocol/transactions/index.md) que se aplicaron al ledger anterior para hacer este.
+- Un **arbol de estado** - Todos los datos en el ledger, como [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md): balances, configuraciones, y demás.
## Ver también
diff --git a/@l10n/es-ES/docs/concepts/ledgers/ledger-close-times.md b/@l10n/es-ES/docs/concepts/ledgers/ledger-close-times.md
index 265e172f62..c34d5da033 100644
--- a/@l10n/es-ES/docs/concepts/ledgers/ledger-close-times.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/ledger-close-times.md
@@ -2,10 +2,11 @@
html: ledger-close-times.html
parent: ledgers.html
seo:
- description: Cómo el XRP Ledger calcula el valor de tiempo de cierre para cada versión del ledger.
+ description: Cómo el XRP Ledger calcula el valor de tiempo de cierre para cada versión del ledger.
labels:
- Blockchain
---
+
# Tiempos de cierre del ledger
La hora exacta en la que la versión del ledger se ha cerrado se queda guardada en el campo `close_time` de la cabecera del ledger o [ledger header](../../references/protocol/ledger-data/ledger-header.md). Para hacer más facil a la red llegar a un consenso en un tiempo de cierre exacto, este valor es redondeado a un número de segundos basado en el momento de resolución del cierre, actualmente 10 segundos. Si redondear causase a un tiempo de cierre ser igual que (o anterior) a su ledger padre, el ledger hijo tendrá su tiempo de cierre igual al tiempo de cierre del ledger padre más 1. Esto garantiza que los tiempos de cierre de los ledgers validados son estríctamente incrementales.
diff --git a/@l10n/es-ES/docs/concepts/ledgers/ledger-structure.md b/@l10n/es-ES/docs/concepts/ledgers/ledger-structure.md
index 0a9c4e1452..3c88354873 100644
--- a/@l10n/es-ES/docs/concepts/ledgers/ledger-structure.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/ledger-structure.md
@@ -2,8 +2,9 @@
html: ledger-structure.html
parent: ledgers.html
seo:
- description: Un vistazo más cercano a los elementos de un bloque de ledger individual.
+ description: Un vistazo más cercano a los elementos de un bloque de ledger individual.
---
+
# La estructura del ledger
El XRP Ledger es una blockchain, lo que quiere decir que consiste en un histórico de bloques de datos consecutivos. Un bloque en la blockchain XRP Ledger se denomina una _versión del ledger_ o _ledger_ abreviado.
@@ -12,12 +13,11 @@ El protocolo de consenso toma la última versión del ledger como punto de parti
Cada versión del ledger contiene _datos de estado_, un _conjunto de transacciones_, y una _cabecera_ que contiene metadatos.
-[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg "Diagrama: Un ledger está formado por una cabecera, un conjunto de transacciones, y datos de estado.")
-
+[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg 'Diagrama: Un ledger está formado por una cabecera, un conjunto de transacciones, y datos de estado.')
## Estado de datos
-[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg "Diagrama: Los datos de estado de un ledger, en forma de varios objetos los cuales a veces están unidos como en un grafo.")
+[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg 'Diagrama: Los datos de estado de un ledger, en forma de varios objetos los cuales a veces están unidos como en un grafo.')
Los _datos de estado_ representan una fotografía de todas las cuentas, balances, configuraciones, y otra información de esta versión del ledger. Cuando un servidor se conecta a la red, una de las primeras cosas que hace es descargar un conjunto completo de los datos de estado actuales para poder procesar nuevas transacciones y responder consultas sobre el estado actual. Como cada servidor de la red tiene una copia completa de los datos del estado, todos los datos son públicos y cada copia es igualmente válida.
@@ -25,7 +25,7 @@ Los datos de estado consisten en objetos individuales llamados _entradas de ledg
## Conjunto de transacciones
-[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg "Diagrama: Un conjunto de transacciones del ledger, un grupo de transacciones organizado en orden canónico.")
+[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg 'Diagrama: Un conjunto de transacciones del ledger, un grupo de transacciones organizado en orden canónico.')
Cada cambio realizado en el ledger es el resultado de una transacción. Cada versión del ledger contiene un _conjunto de transacciones_ que es un grupo de transacciones que se han aplicado recientemente en un orden específico. Si tomas los datos de estado de la versión anterior del ledger y aplicas este conjunto de transacciones del ledger encima de él, obtienes los datos de estado de este ledger como resultado.
@@ -34,33 +34,30 @@ Cada transacción en el conjunto del ledger tiene ambas de la siguientes partes:
- _Instrucciones de la transaccion_ mostrando lo que el remitente le pidió hacer.
- _Metadatos de la transacción_ mostrando exáctamente cómo la transacción debe ser procesada y cómo afecta a los datos de estado del ledger.
-
## Cabecera del ledger
La _cabecera del ledger_ es un bloque de datos que resume la versión del ledger. Como la portada de un informe, identifica de forma única la versión del ledger, enumera sus contenidos, y muestra la hora en la que se creó, junto con algunas otras notas. La cabecera del ledger contiene la siguiente información:
-- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg "") El _ledger index_, o índice del ledger identifica la posición del ledger en la cadena. Se construye en el ledger con un índice restando uno, hasta llegar hasta el punto de inicio llamado como el _genesis ledger_. Esto forma un histórico público con todas las trnasacciones y resultados.
-- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg "") El _ledger hash_, que identifica de manera única los contenidos del ledger. El hash es calculado de manera que si cambia algún detalle, la versión del ledger cambia, el hash es completamente diferente, lo que lo convierte también en un checksum que muestra que ninguno de los datos en el ledger se ha perdido, modificado, o corrompido.
-- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg "") El _parent ledger hash_ o el hash del ledger padre. Una versión del ledger es definida en gran parte por la diferencia con el _parent ledger_ que viene antes de el, por lo que la cabecera también contiene el hash único para su ledger padre.
-- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg "") El _close time_ u hora de cierre, la timestamp que marca cuando se finalizaron los contenidos del ledger. Este número se redondea por un número de segundos, generalmente 10.
-- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg "") Un _hash de datos del estado_ el cual actua de checksum para los datos del estado.
-- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg "") Un _hash del conjunto de transacciones_ el cual actua como checksum de los datos del conjuntos de transacciones.
-- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg "") Algunas otras notas como la cantidad total de XRP en existencia y la cantidad que se redondeó la hora de cierre.
+- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg) El _ledger index_, o índice del ledger identifica la posición del ledger en la cadena. Se construye en el ledger con un índice restando uno, hasta llegar hasta el punto de inicio llamado como el _genesis ledger_. Esto forma un histórico público con todas las trnasacciones y resultados.
+- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg) El _ledger hash_, que identifica de manera única los contenidos del ledger. El hash es calculado de manera que si cambia algún detalle, la versión del ledger cambia, el hash es completamente diferente, lo que lo convierte también en un checksum que muestra que ninguno de los datos en el ledger se ha perdido, modificado, o corrompido.
+- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg) El _parent ledger hash_ o el hash del ledger padre. Una versión del ledger es definida en gran parte por la diferencia con el _parent ledger_ que viene antes de el, por lo que la cabecera también contiene el hash único para su ledger padre.
+- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg) El _close time_ u hora de cierre, la timestamp que marca cuando se finalizaron los contenidos del ledger. Este número se redondea por un número de segundos, generalmente 10.
+- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg) Un _hash de datos del estado_ el cual actua de checksum para los datos del estado.
+- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg) Un _hash del conjunto de transacciones_ el cual actua como checksum de los datos del conjuntos de transacciones.
+- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg) Algunas otras notas como la cantidad total de XRP en existencia y la cantidad que se redondeó la hora de cierre.
Un conjunto de transacciones y los datos de estado son ilimitados en espacio, pero la cabecera del ledger siempre es de un tamaño fijo. Para los datos exactos y el formato binario de una cabecera del ledger, ver [Cabecera del leder](../../references/protocol/ledger-data/ledger-header.md).
-
## Estado de validación
-[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg "Diagrama: Un estado de validación de un ledger, el cual es añadido encima del ledger y no es parte del ledger en sí.")
+[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg 'Diagrama: Un estado de validación de un ledger, el cual es añadido encima del ledger y no es parte del ledger en sí.')
Cuando un consenso de la Lista de Nodos Únicos de un servidor está de acuerdo en los contenidos de una versión del ledger, esa versión del ledger es marcada como validada e inmutable. Los contenidos del ledger solo pueden cambiar mediante transacciones posteriores que creen una nueva versión del ledger, continuando la cadena.
Cuando una versión del ledger es creada por primera vez, no está todavía validada. Debido a las diferencias en cuanto llegan las transacciones a diferentes servidores, la red puede construir y proponer múltiples versiones diferentes del ledger para ser el siguiente en la cadena. El [protocolo de consenso](../consensus-protocol/index.md) decide cual de ellas se valida. (Las transacciones candidatas que no estén en la versión del ledger validado pueden generalmente incluirse en el conjunto de transacciones la siguiente versión del ledger en su lugar.)
-
## ¿Índice del ledger o Hash del ledger?
Hay dos formas diferentes de identificar la versión del ledger: Su _ledger index_ o índice del ledger y su _ledger hash_ o hash del ledger. Estos dos campos identifican un ledger, pero tienen propósitos distintos. El índice del ledger te informa de la posición del ledger en la cadena, y el hash del ledger refleja los contenidos del ledger.
diff --git a/@l10n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md b/@l10n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md
index a33105b045..972914b897 100644
--- a/@l10n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md
+++ b/@l10n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md
@@ -2,23 +2,24 @@
html: open-closed-validated-ledgers.html
parent: ledgers.html
seo:
- description: Los objetos del ledger tienen uno de los tres estados — abierto, cerrado, o validado.
+ description: Los objetos del ledger tienen uno de los tres estados — abierto, cerrado, o validado.
labels:
- Blockchain
---
+
# Ledgers abiertos, cerrados, y validados
El servidor `rippled` hace una distinción entre versiones de ledgers que están _abiertas_, _cerradas_, y _validadas_. Un servidor tiene un ledger abierto, cualquier número de ledgers cerrados pero no validados, y un historial inmutable de ledgers validados. La siguiente tabla resume las diferencias:
-| Tipo de ledger: | Abierto | Cerrado | Validado |
-|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
-| **Propósito:** | Espacio de trabajo temporal | Próximo estado propuesto | Estado previo confirmado |
-| **Número usado:** | 1 | Cualquier número, normalmente 0 o 1 | Uno por ledger index, crece con el tiempo |
-| **¿Pueden los contenidos cambiar?** | Sí | No, pero el ledger completo se podría reemplazar | Nunca |
-| **Transacciones se aplican en:** | El orden que son recibidas | Orden canónico | Orden canónino |
+| Tipo de ledger: | Abierto | Cerrado | Validado |
+| :---------------------------------- | :-------------------------- | :----------------------------------------------- | :---------------------------------------- |
+| **Propósito:** | Espacio de trabajo temporal | Próximo estado propuesto | Estado previo confirmado |
+| **Número usado:** | 1 | Cualquier número, normalmente 0 o 1 | Uno por ledger index, crece con el tiempo |
+| **¿Pueden los contenidos cambiar?** | Sí | No, pero el ledger completo se podría reemplazar | Nunca |
+| **Transacciones se aplican en:** | El orden que son recibidas | Orden canónico | Orden canónino |
No intuitivamente, el XRP Ledger nunca "cierra" un ledger abierto para convertirlo en un ledger cerrado. En cambio, el servidor descarta el ledger abierto, crea un nuevo ledger cerrado aplicando transacciones encima de los ledgers cerrados previos, entonces crea un nuevo ledger abierto utilizando el último ledger cerrado como base. Esto es una consecuencia de [cómo el consenso resuelve el problema del doble gasto](../consensus-protocol/consensus-principles-and-rules.md#simplificando-el-problema).
Para un ledger abierto, los servidores aplican transacciones en el orden en el que esas transacciones aparecen, pero diferentes servidores puede que vean transacciones en diferentes órdenes. Como no hay un vigilante del tiempo para decidir qué transacción fue actualmente la primera, los servidores pueden no estar de acuerdo en el orden exacto de las transacciones que fueron enviadas casi al mismo tiempo. Por lo tanto, el proceso para calcular una versión de ledger cerrado que es elegible para [validación](../consensus-protocol/consensus-structure.md#validación) es diferente que el proceso de construir un ledger abierto con transacciones propuestas en su orden de llegada. Para crear un ledger "cerrado", cada servidor XRP Ledger comienza con un cojunto de transacciones y una versión anterior de ledger, o "padre". El servidores pone las transacciones en orden canónico, después las aplica al anterior ledger en ese orden. El orden canónico está diseñado para ser determinístico y eficiente, pero dificil de manipular, para incrementar la dificultad de adelantarse (o front-running) a las Ofertas en el [exchange descentralizado](../tokens/decentralized-exchange/index.md).
-Por lo tanto, un ledger abierto es solo utilizado como un espacio de trabajo temporal, lo cual es una de las principales razones por las cuales [los resultados tentativos pueden variar de los resultados finales](../transactions/finality-of-results/index.md) en las transacciones.
+Por lo tanto, un ledger abierto es solo utilizado como un espacio de trabajo temporal, lo cual es una de las principales razones por las cuales [los resultados tentativos pueden variar de los resultados finales](../transactions/finality-of-results/index.md) en las transacciones.
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/amendments.md b/@l10n/es-ES/docs/concepts/networks-and-servers/amendments.md
index a9c7663edc..1585a95759 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/amendments.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/amendments.md
@@ -2,13 +2,14 @@
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.
+ 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.
+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.
@@ -29,15 +30,14 @@ Cada 256º ledger se llama **flag** ledger. El flag ledger no tiene contenidos e
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.
+ - 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.
+ **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.
@@ -48,16 +48,16 @@ Las enmiendas deben mantener dos semanas el apoyo de más del 80% de los validad
Las enmiendas que hayan tenido su código fuente removido sin haberse activado on consideradas **vetadas** por la red.
-
## Servidores bloqueados por enmienda
+
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.
+- 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.
@@ -73,16 +73,15 @@ Cuando las enmiendas son activadas, el código fuente de comportamientos previos
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)
+ - [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)
+ - [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)
+ - [Enmiendas conocidas](/resources/known-amendments.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/clustering.md b/@l10n/es-ES/docs/concepts/networks-and-servers/clustering.md
index 7fa50c6afc..713e959297 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/clustering.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/clustering.md
@@ -2,10 +2,11 @@
html: clustering.html
parent: networks-and-servers.html
seo:
- description: Ejecuta servidores rippled en un cluster para compartir la carga criptográfica entre ellos.
+ 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:
@@ -19,11 +20,11 @@ Si estás ejecutando un validador como un [par privado](peer-protocol.md#pares-p
## 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)
+ - [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)
+ - [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" /%}
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/index.md b/@l10n/es-ES/docs/concepts/networks-and-servers/index.md
index d58c5b42f3..b8b0181c8e 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/index.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/index.md
@@ -2,10 +2,11 @@
html: networks-and-servers.html
parent: concepts.html
seo:
- description: rippled es el servidor peer-to-peer principal que maneja el XRP Ledger.
+ 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:
@@ -17,15 +18,15 @@ Cualquiera puede ejecutar instancias de uno o ambos de estos tipos de servidores
## 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.
+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.
+- 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.
@@ -37,5 +38,4 @@ Finalmente, si ejecutas un servidor de validación, puedes utilizar un servidor
{% raw-partial file="/docs/_snippets/common-links.md" /%}
-
{% child-pages /%}
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md b/@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md
index 11fd455d6b..e6fc08c9ad 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md
@@ -2,12 +2,13 @@
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.
+ 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.
@@ -34,17 +35,16 @@ Rellenar el histórico es uno de las prioridades más bajas del servidor, por lo
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.
-
+
### 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).
-
-
## 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**.
@@ -58,22 +58,21 @@ Los proveedores de servidores Full History se reservan el derecho de bloquear ac
Para instrucciones de cómo configurar un servidor full history, consultar [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
-
## Ver también
- **Conceptos:**
- - [Ledgers](../ledgers/index.md)
- - [Consenso](../consensus-protocol/index.md)
+ - [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 Full History](../../infrastructure/configuration/data-retention/configure-full-history.md)
+ - [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 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][]
+ - [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" /%}
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/parallel-networks.md b/@l10n/es-ES/docs/concepts/networks-and-servers/parallel-networks.md
index fc075939a9..6ad5b2fa33 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/parallel-networks.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/parallel-networks.md
@@ -2,49 +2,48 @@
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.
+ 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. |
+| 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. |
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)
+ - [XRP Testnet Faucet](/resources/dev-tools/xrp-faucets)
- **Conceptos:**
- - [Consenso](../consensus-protocol/index.md)
- - [Enmiendas](amendments.md)
+ - [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)
+ - [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)
+ - [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" /%}
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md b/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
index d70f958c7d..71b6306c0d 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
@@ -2,11 +2,12 @@
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í.
+ 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.
@@ -24,13 +25,12 @@ Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando
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.
+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.)
@@ -58,7 +58,6 @@ El par de claves de nodo se guarda en la base de datos y se reutiliza cuando el
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:
@@ -71,10 +70,9 @@ En los siguientes casos, un servidor `rippled` no se conecta a pares no confiabl
- 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.
+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.
@@ -84,9 +82,9 @@ Configurar un servidor como un servidor privado tiene varios efectos:
- 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.
+ 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.
+ **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
@@ -98,7 +96,6 @@ Para ser parte del XRP Ledger, un servidor `rippled` debe estar conectado al res
Los pros y contras de cada configuración son los siguientes:
-
Configuración
Pros
Contras
@@ -148,27 +145,26 @@ Los pros y contras de cada configuración son los siguientes:
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)
+ - [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)
+ - [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)
+ - [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" /%}
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md b/@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md
index 97756ac013..7360b2d079 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md
@@ -2,25 +2,25 @@
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.
+ 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.
+ - [**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 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.
@@ -33,15 +33,13 @@ Los servidores en Modo P2P también pueden configurarse para proporcionar funcio
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.
-
+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
@@ -65,7 +63,6 @@ Puedes habilitar de forma segura la validación en un servidor que también se u
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 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:
@@ -74,11 +71,10 @@ En el modo solitario, el servidor opera sin conectarse a la red y sin participar
- [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)
+ - [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" /%}
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/the-clio-server.md b/@l10n/es-ES/docs/concepts/networks-and-servers/the-clio-server.md
index c910cc7980..db6e8f4a58 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/the-clio-server.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/the-clio-server.md
@@ -2,8 +2,9 @@
html: the-clio-server.html
parent: networks-and-servers.html
seo:
- description: Clio es un servidor XRP Ledger optimizado para llamadas API.
+ 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.
@@ -18,20 +19,19 @@ Mientras que Clio ofrece las [APIs HTTP / WebSocket](../../references/http-webso
## ¿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.
+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.
+- 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`.
+- 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.
+- 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?")
+[{% 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.
@@ -48,4 +48,4 @@ Clio **siempre** reenvía a `rippled` si alguna de las siguientes condiciones es
- [Código fuente Clio](https://github.com/XRPLF/clio)
- **Tutoriales:**
- - [Instalar servidor Clio en Ubuntu](../../infrastructure/installation/install-clio-on-ubuntu.md)
+ - [Instalar servidor Clio en Ubuntu](../../infrastructure/installation/install-clio-on-ubuntu.md)
diff --git a/@l10n/es-ES/docs/concepts/networks-and-servers/transaction-censorship-detection.md b/@l10n/es-ES/docs/concepts/networks-and-servers/transaction-censorship-detection.md
index 5fe5ed841e..fc7bf91e01 100644
--- a/@l10n/es-ES/docs/concepts/networks-and-servers/transaction-censorship-detection.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/transaction-censorship-detection.md
@@ -2,10 +2,11 @@
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.
+ 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 %}
@@ -14,8 +15,6 @@ El XRP Ledger está diseñado para ser resistente a la censura. En apoyo a este
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:
@@ -26,9 +25,9 @@ A alto nivel, así es cómo el detector de censura de transacciones funciona:
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.
+ 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.
+ 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
@@ -38,7 +37,6 @@ Esto es un ejemplo de mensaje de advertencia emitido por el detector de censura
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.
@@ -47,7 +45,6 @@ Este es un ejemplo de mensaje de error emitido por el detector de censura de tra
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.
@@ -60,18 +57,17 @@ Aquí hay algunos escenarios que podrían causar que el detector emita mensajes
- 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/).
-
+ 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)
+ - [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)
+ - [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)
+ - [Resultados de transacciones](../../references/protocol/transactions/transaction-results/index.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/payment-types/bouncing-payments.md b/@l10n/es-ES/docs/concepts/payment-types/bouncing-payments.md
index e70bd3d950..ec6315f06d 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/bouncing-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/bouncing-payments.md
@@ -2,10 +2,11 @@
html: bouncing-payments.html
parent: payment-types.html
seo:
- description: Cuando el propósito de un pago no esté claro, devuélvelo al remitente.
+ description: Cuando el propósito de un pago no esté claro, devuélvelo al remitente.
labels:
- Tokens
---
+
# Devolver pagos
Cuando una de tus direcciones recibe un pago cuyo propósito no está claro, te recomendamos que intentes devolver el dinero a su remitente. Si bien esto requiere más trabajo que quedarse con el dinero, demuestra buena fe hacia los clientes. Puedes hacer que un operador rechace los pagos manualmente o crear un sistema para hacerlo automáticamente.
diff --git a/@l10n/es-ES/docs/concepts/payment-types/checks.md b/@l10n/es-ES/docs/concepts/payment-types/checks.md
index 3bb908f04b..15b2dd89ad 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/checks.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/checks.md
@@ -2,14 +2,14 @@
html: checks.html
parent: payment-types.html
seo:
- description: Los cheques permiten a los usuarios a crear pagos diferidos que pueden ser cancelados o cobrados por los destinatarios deliberados.
+ description: Los cheques permiten a los usuarios a crear pagos diferidos que pueden ser cancelados o cobrados por los destinatarios deliberados.
labels:
- Cheques
- Pagos
- Tokens
---
-# Cheques
+# Cheques
La función de Cheques permite a los usuarios crear pagos aplazados similares a cheques en papel. A diferencia de un depósito en garantía (escrow) o canal de pago (payment channel), los fondos no se reservan cuando se crea un cheque, por lo que el dinero solo se mueve cuando se cobra el cheque. Si el remitente no tiene los fondos en el momento en que se cobra un cheque, la transacción falla; los destinatarios pueden intentar nuevamente las transacciones fallidas hasta que el cheque expire.
@@ -23,44 +23,41 @@ Los Cheques del XRP Ledger pueden tener tiempos de vencimiento después de los c
- Cobros de cheques flexibles. El destnatario puede canjear el Cheque entre un nínimo y un máximo.
-
## Ciclo de vida de un cheque
1. El remitente envía una [transacción CheckCreate][], que define:
- - El destinatario.
- - Una fecha de caducidad.
- - La cantidad máxima que se puede cargar de su cuenta.
+ - El destinatario.
+ - Una fecha de caducidad.
+ - La cantidad máxima que se puede cargar de su cuenta.
-2. Cuando una transacción es procesada, el XRP Ledger crea un objeto `Check`. El cheque puede ser cancelado por el destinatario o el remitente con una [transacción CheckCancel][].
+2. Cuando una transacción es procesada, el XRP Ledger crea un objeto `Check`. El cheque puede ser cancelado por el destinatario o el remitente con una [transacción CheckCancel][].
3. El destinatario envía una [transacción CheckCash][] que transfiere los fondos y destruye el objeto `Check`. Los destinatarios tienen dos opciones para cobrar los cheques:
- - Cantidad exacta: Se especifica la cantidad exacta de dinero a cobrar que no puede exceder el máximo del cheque.
- - Cantidad flexible: Se especifica una cantidad mínima para cobrar y el XRP Ledger manda tanto como sea posible hasta el máximo del cheque. Si el remitente no tiene fondos para cumplir al menos el mínimo específicado, la transacción falla.
+ - Cantidad exacta: Se especifica la cantidad exacta de dinero a cobrar que no puede exceder el máximo del cheque.
+ - Cantidad flexible: Se especifica una cantidad mínima para cobrar y el XRP Ledger manda tanto como sea posible hasta el máximo del cheque. Si el remitente no tiene fondos para cumplir al menos el mínimo específicado, la transacción falla.
4. Si el cheque vence antes de que el destinatario lo cobre, el objeto `Check` permanece hasta que alguien lo cancele.
-
-
## Ver también
Para más información sobre Cheques en el XRP Ledger, ver:
- [Referencia transacción](../../references/protocol/transactions/types/index.md)
- - [CheckCreate][]
- - [CheckCash][]
- - [CheckCancel][]
+ - [CheckCreate][]
+ - [CheckCash][]
+ - [CheckCancel][]
- [Tutoriales de cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/index.md)
- - [Enviar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md)
- - [Buscar cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks.md)
- - [Canjear un cheque por la cantidad exacta](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-an-exact-amount.md)
- - [Canjear un cheque por una cantidad flexible](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md)
- - [Cancelar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cancel-a-check.md)
+ - [Enviar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md)
+ - [Buscar cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks.md)
+ - [Canjear un cheque por la cantidad exacta](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-an-exact-amount.md)
+ - [Canjear un cheque por una cantidad flexible](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md)
+ - [Cancelar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cancel-a-check.md)
- [Enmienda Cheques][]
Para más información sobre funciones relacionadas, ver:
-* [Autorización de deposito](../accounts/depositauth.md)
-* [Escrow](escrow.md)
-* [Tutorial de canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)
+- [Autorización de deposito](../accounts/depositauth.md)
+- [Escrow](escrow.md)
+- [Tutorial de canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/payment-types/cross-currency-payments.md b/@l10n/es-ES/docs/concepts/payment-types/cross-currency-payments.md
index b973833746..81f7532dfc 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/cross-currency-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/cross-currency-payments.md
@@ -2,41 +2,39 @@
html: cross-currency-payments.html
parent: payment-types.html
seo:
- description: Los pagos entre divisas entregan atómicamente una moneda diferente a la que envían mediante la conversión a través de rutas y libros de pedidos.
+ description: Los pagos entre divisas entregan atómicamente una moneda diferente a la que envían mediante la conversión a través de rutas y libros de pedidos.
labels:
- Entre divisas
- Pagos
---
+
# Pagos entre divisas
El XRP Ledger te permite realizar pagos entre divisas de XRP y tokens. Los pagos entre divisas dentro del XRP Ledger son complétamente atómicos, lo que quiere decir que el pago se ejecuta por completo o no se ejecuta en absoluto.
Por defecto, los pagos entre divisas entregan una cantidad fija a su destino a un coste variable para su origen. Los pagos entre divisas también pueden ser [pagos parciales](partial-payments.md) que entregan una cantidad variable dentro de un límite de envío establecido.
-
## Prerrequisitos
- Por definición, un pago entre divisas implica al menos dos monedas, lo que significa que al menos una fivisa involucrada debe ser un [token](../tokens/index.md) que no sea XRP.
- Debe existir al menos una ruta o [Path](../tokens/fungible-tokens/paths.md) entre el remitente y el receptor, y la liquidez total a lo largo de todas las rutas debe ser suficiente para ejecutar el pago. Los pagos entre divisas se convierten de una divisa a otra consumiendo ofertas u [Offers](../tokens/decentralized-exchange/offers.md) en el [exchange descentralizado](../tokens/decentralized-exchange/index.md) del XRP Ledger.
-
## Auto-puente
Los pagos entre divisas que intercambian un token por otro token pueden utilizar automáticamente XRP como puente entre los tokens, cuando esto reduce el coste del pago. Por ejemplo, un pago que envía de USD a MXN convierte automáticamente USD a XRP y luego XRP a MXN si hacerlo es más barato que convertir USD a MXN diréctamente. Operaciones más grandes pueden utilizar una combinación de conversiones directas (USD-MXN) y puentes automáticos (USD-XRP-MXN).
Para más información, ver auto-puente o [Auto-Bridging](../tokens/decentralized-exchange/autobridging.md).
-
## Ver también
- **Conceptos:**
- - [Tokens](../tokens/index.md)
- - [Exchange descentralizado](../tokens/decentralized-exchange/index.md)
- - [Paths](../tokens/fungible-tokens/paths.md)
+ - [Tokens](../tokens/index.md)
+ - [Exchange descentralizado](../tokens/decentralized-exchange/index.md)
+ - [Paths](../tokens/fungible-tokens/paths.md)
- **References:**
- - [Tipos de transacciones de pago][Payment transaction]
- - [método path_find][]
- - [método ripple_path_find][]
- - [Interpretando metadatos de pagos entre divisas](../transactions/finality-of-results/look-up-transaction-results.md#token-payments)
+ - [Tipos de transacciones de pago][Payment transaction]
+ - [método path_find][]
+ - [método ripple_path_find][]
+ - [Interpretando metadatos de pagos entre divisas](../transactions/finality-of-results/look-up-transaction-results.md#token-payments)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md b/@l10n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md
index 8178e8b9e1..8eaf4686a6 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md
@@ -2,48 +2,44 @@
html: direct-xrp-payments.html
parent: payment-types.html
seo:
- title: Pagos directos en XRP
- description: Los pagos directos en XRP son la forma más rápida y sencilla de enviar valor en el XRP Ledger. Conoce ahora los conceptos básicos del ciclo de vida de pago directo en XRP.
+ title: Pagos directos en XRP
+ description: Los pagos directos en XRP son la forma más rápida y sencilla de enviar valor en el XRP Ledger. Conoce ahora los conceptos básicos del ciclo de vida de pago directo en XRP.
labels:
- XRP
- Pagos
---
+
# Pagos directos en XRP
La base de cualquier sistema financiero es la transferencia de valor. El método más rápido y sencillo en el XRP Ledger es un pago directo en XRP de una cuenta a otra. A diferencia de otros métodos de pago que requieren múltiples transacciones para completarse, un pago directo en XRP se ejecuta en una sola transacción sin intermediarios, y típicamente se completa en 8 segundos o menos. Solo puedes hacer pagos directos cuando XRP es la moneda enviada y recibida.
-
-
## Ciclo de vida de pagos XRP directos
1. El remitente crea una [transacción Payment][], que define los parámetros del pago. La transacción es un pago directo en XRP si XRP es la divisa enviada y recibida.
2. El procesamiento de la transacción verifica los parámetros y circunstancias de la transacción; si la comprobación falla, el pago falla.
+ - Todos los campos están formateados correctamente.
+ - La dirección de envío es una cuenta activada en el XRP Ledger.
+ - Todas las firmas proporcionadas son válidas para la dirección de envío.
+ - La dirección de destino es diferente que la dirección de envío.
+ - El remitente tiene suficiente XRP en balance para enviar el pago.
- - Todos los campos están formateados correctamente.
- - La dirección de envío es una cuenta activada en el XRP Ledger.
- - Todas las firmas proporcionadas son válidas para la dirección de envío.
- - La dirección de destino es diferente que la dirección de envío.
- - El remitente tiene suficiente XRP en balance para enviar el pago.
-
-2. El procesamiento del pago comprueba la dirección de destino; si alguna comprobación falla, el pago falla.
-
- - Si la dirección de recepción está activada, el motor hace comprobaciones adicionales basados en sus configuraciones, como la autorización de depósito o [Deposit Authorization](../accounts/depositauth.md).
- - Si la dirección de recepción no está activada, comprueba si el pago enviará suficiente XRP para cumplir con el mínimo del requisito de la [reserva de cuenta](../accounts/reserves.md). Si la reserva se cumple, una nueva cuenta es creada para la dirección y el balance inicial es la cantidad recibida.
+3. El procesamiento del pago comprueba la dirección de destino; si alguna comprobación falla, el pago falla.
+ - Si la dirección de recepción está activada, el motor hace comprobaciones adicionales basados en sus configuraciones, como la autorización de depósito o [Deposit Authorization](../accounts/depositauth.md).
+ - Si la dirección de recepción no está activada, comprueba si el pago enviará suficiente XRP para cumplir con el mínimo del requisito de la [reserva de cuenta](../accounts/reserves.md). Si la reserva se cumple, una nueva cuenta es creada para la dirección y el balance inicial es la cantidad recibida.
4. El ledger quita y acredita a las correspondientes cuentas.
-
- **Nota:** Al remitente también se le carga el [coste de transacción](../transactions/transaction-cost.md) en XRP.
-
+
+ **Nota:** Al remitente también se le carga el [coste de transacción](../transactions/transaction-cost.md) en XRP.
## Ver también
- **Tutoriales:**
- - [Enviar XRP (Tutorial interactivo)](../../tutorials/how-tos/send-xrp.md)
- - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+ - [Enviar XRP (Tutorial interactivo)](../../tutorials/how-tos/send-xrp.md)
+ - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
- **Referencias:**
- - [Transacción Payment][]
- - [Resultados de Transaction](../../references/protocol/transactions/transaction-results/index.md)
- - [método account_info][] - para comprobar balances en XRP
+ - [Transacción Payment][]
+ - [Resultados de Transaction](../../references/protocol/transactions/transaction-results/index.md)
+ - [método account_info][] - para comprobar balances en XRP
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/payment-types/escrow.md b/@l10n/es-ES/docs/concepts/payment-types/escrow.md
index d5b74ba7d2..972a280b58 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/escrow.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/escrow.md
@@ -2,10 +2,11 @@
html: escrow.html
parent: payment-types.html
seo:
- description: El Escrow retiene fondos hasta que las condiciones específicas se cumplan.
+ description: El Escrow retiene fondos hasta que las condiciones específicas se cumplan.
labels:
- Escrow
---
+
# Escrow
Tradicionalmente, un escrow es un contrato entre dos partes para facilitar transacciones financieras. Un tercero imparcial recibe y retiene los fondos, y solo los libera al destinatario previsto cuando se cumplen las condiciones especificadas en el contrato. Este método asegura que ambas partes cumplan con sus obligaciones.
@@ -23,16 +24,15 @@ El XRP Ledger soporta tres tipos de escrow:
## Ciclo de vida de un escrow
1. El remitente crea un escrow utilizando la transacción `EscrowCreate`. Esta transacción define:
-
- - Una cantidad de XRP para bloquear.
- - Las condiciones para liberar el XRP.
- - El destinatario del XRP.
+ - Una cantidad de XRP para bloquear.
+ - Las condiciones para liberar el XRP.
+ - El destinatario del XRP.
2. Cuando se procesa la transacción, el XRP Ledger crea un objeto `Escrow` que retiene el XRP en el escrow.
3. El destinatario envía una transacción `EscrowFinish` para entregar el XRP. Si las condiciones se han cumplido, esto destruye el objeto `Escrow` y entrega el XRP al destinatario.
- **Nota:** Si el escrow tiene una fecha de caducidad y no se completa con éxito antes de este tiempo, el escrow se caduca. Un escrow caducado permanece en el ledger hasta que una transacción `EscrowCancel` lo cancele, destruyendo el objeto `Escrow` y devuelve el XRP al remitente.
+ **Nota:** Si el escrow tiene una fecha de caducidad y no se completa con éxito antes de este tiempo, el escrow se caduca. Un escrow caducado permanece en el ledger hasta que una transacción `EscrowCancel` lo cancele, destruyendo el objeto `Escrow` y devuelve el XRP al remitente.
## Estados del escrow
@@ -48,18 +48,16 @@ El diagrama muestra tres casos diferentes para tres posibles combinaciones de lo
- **Escrow condicional (derecha):** Si el escrow especifica una criptocondición (campo `Condition`) y no por una fecha "terminar trás", el escrow se convierte en **Condicionalmente preparado** inmediatamente cuando se crea. Durante este tiempo, cualquiera puede finalizar el escrow, pero solo si suministran el cumplimiento correcto a la criptocondición. Si nadie finaliza el escrow antes de la fecha de caducidad (campo `CancelAfter`), el escrow se convierte en **Caducado**. (Un escrow sin una fecha de "finalizar-tras" _debe_ tener una fecha de caducidad.) En el estado de caducado, el escrow no puede ser finalizado, y cualquiera puede cancelarlo.
-
## Limitaciones
- El escrow solo funciona con XRP, no con tokens.
- Los costes pueden hacerlo poco práctico para cantidades pequeñas.
- - El escrow requiere de dos transacciones: una para crear el escrow, y una para finalizarlo o cancelarlo. Las criptocondiciones incurren en un [coste de transacción](../transactions/transaction-cost.md) mayor al usual.
- - Mientras que el escrow no se completa, el remitente es responsable del [requisito de reserva](../accounts/reserves.md) del objeto del `Escrow`.
+ - El escrow requiere de dos transacciones: una para crear el escrow, y una para finalizarlo o cancelarlo. Las criptocondiciones incurren en un [coste de transacción](../transactions/transaction-cost.md) mayor al usual.
+ - Mientras que el escrow no se completa, el remitente es responsable del [requisito de reserva](../accounts/reserves.md) del objeto del `Escrow`.
- No puedes crear un escrow con valores de fechas pasados.
- Las liberaciones y caducidad se resuelven en [tiempos de cierre de ledgers](../ledgers/ledger-close-times.md). En la práctica, los tiempos de liberaciones o caducidad pueden variar en 5 segundos respecto a los cierres de ledgers.
- El único tipo de criptocondición aceptado es PREIMAGE-SHA-256.
-
## Coste de la transacción EscrowFinish
Cuando uses criptocondiciones, la transacción EscrowFinish debe pagar un [mayor coste de transacción](../transactions/transaction-cost.md#special-transaction-costs) por la carga de procesamiento involucrada en la verificación de la criptocondición introducida.
@@ -76,20 +74,17 @@ Si el [coste de votar](../consensus-protocol/fee-voting.md) cambia el valor de `
reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
```
-
-
## Ver también
Para más información sobre Escrow en el XRP Ledger, consulta lo siguiente:
- [Tutoriales Escrow](../../tutorials/how-tos/use-specialized-payment-types/use-escrows/index.md)
- [Referencia de transacciones](../../references/protocol/transactions/index.md)
- - [Transacción EscrowCreate][]
- - [Transacción EscrowFinish][]
- - [Transacción EscrowCancel][]
+ - [Transacción EscrowCreate][]
+ - [Transacción EscrowFinish][]
+ - [Transacción EscrowCancel][]
- [Referencia Ledger](../../references/protocol/ledger-data/index.md)
- - [Objeto Escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
-
+ - [Objeto Escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
Para más información sobre el bloqueo de 55 mil millones de Ripple, consulta [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/).
diff --git a/@l10n/es-ES/docs/concepts/payment-types/index.md b/@l10n/es-ES/docs/concepts/payment-types/index.md
index bec5055e9d..5c5f39824e 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/index.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/index.md
@@ -4,13 +4,12 @@ parent: concepts.html
metadata:
indexPage: true
seo:
- title: Point-to-Point & Specialized Ledger Payment Types
- description: Mientras que el XRP Ledger admite pagos XRP de punto a punto, también es compatible con tipos de pago más especializados. Descubre qué métodos de pago del ledger aquí.
+ title: Point-to-Point & Specialized Ledger Payment Types
+ description: Mientras que el XRP Ledger admite pagos XRP de punto a punto, también es compatible con tipos de pago más especializados. Descubre qué métodos de pago del ledger aquí.
---
-# Ledger Payment Types
+# Ledger Payment Types
El XRP Ledger admite pagos de XRP de punto a punto junto con otros tipos de pago más especializados.
-
{% child-pages /%}
diff --git a/@l10n/es-ES/docs/concepts/payment-types/partial-payments.md b/@l10n/es-ES/docs/concepts/payment-types/partial-payments.md
index 27a76af4bf..ddf6c83f97 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/partial-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/partial-payments.md
@@ -2,11 +2,12 @@
html: partial-payments.html
parent: payment-types.html
seo:
- description: Los pagos parciales restan costes a la cantidad enviada, entregando una cantidad flexible. Los pagos parciales son útiles para devolver pagos no deseados sin incurrir en costes adicionales.
+ description: Los pagos parciales restan costes a la cantidad enviada, entregando una cantidad flexible. Los pagos parciales son útiles para devolver pagos no deseados sin incurrir en costes adicionales.
labels:
- Pagos
- Seguridad
---
+
# Pagos parciales
El remitente de cualquier [transacción de pago][] puede habilitar el [flag de"Partial Payment"](../../references/protocol/transactions/types/payment.md#payment-flags) y enviar un pago que entregue menos de lo que indica el campo `Amount`. Al procesar cualquier Pago, utiliza el campo de metadatos `delivered_amount`, no el campo `Amount`. El `delivered_amount` es la cantidad que un pago realmente entregó.
@@ -51,7 +52,7 @@ Los pagos parciales tienen las siguientes limitaciones:
- Un pago parcial no puede proporcionar el XRP para crear una dirección; en este caso se devuelve el [código de resultado][] `telNO_DST_PARTIAL`.
- Pagos directoss de XRP a XRP no pueden ser pagos parciales; este caso devuelve el [código de resultado][] `temBAD_SEND_XRP_PARTIAL`.
- - Sin embargo, los pagos entre divisas que involucran a XRP como una de las divisas _pueden_ ser pagos parciales.
+ - Sin embargo, los pagos entre divisas que involucran a XRP como una de las divisas _pueden_ ser pagos parciales.
[código de resultado]: ../../references/protocol/transactions/transaction-results/index.md
@@ -70,15 +71,15 @@ Si ambas condiciones son verdaderas, entonces `delivered_amount` contiene el val
Puedes encontrar el campo `delivered_amount` en los siguientes lugares:
-| API | Método | Campo |
-|-----|--------|-------|
-| [JSON-RPC / WebSocket][] | [método account_tx][] | `result.transactions` miembros del array `meta.delivered_amount` |
-| [JSON-RPC / WebSocket][] | [método tx][] | `result.meta.delivered_amount` |
-| [JSON-RPC / WebSocket][] | [método transaction_entry][] | `result.metadata.delivered_amount` |
-| [JSON-RPC / WebSocket][] | [método ledger][] (con las transacciones ampliadas) | `result.ledger.transactions` miembros del array `metaData.delivered_amount` |
-| [WebSocket][] | [subscripciones Transaction](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Mensajes de subscripción de `meta.delivered_amount` |
-| ripple-lib v1.x | método `getTransaction` | `outcome.deliveredAmount` |
-| ripple-lib v1.x | método `getTransactions` | miembros del array `outcome.deliveredAmount` |
+| API | Método | Campo |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| [JSON-RPC / WebSocket][] | [método account_tx][] | `result.transactions` miembros del array `meta.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [método tx][] | `result.meta.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [método transaction_entry][] | `result.metadata.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [método ledger][] (con las transacciones ampliadas) | `result.ledger.transactions` miembros del array `metaData.delivered_amount` |
+| [WebSocket][] | [subscripciones Transaction](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Mensajes de subscripción de `meta.delivered_amount` |
+| ripple-lib v1.x | método `getTransaction` | `outcome.deliveredAmount` |
+| ripple-lib v1.x | método `getTransactions` | miembros del array `outcome.deliveredAmount` |
[WebSocket]: ../../references/http-websocket-apis/index.md
[JSON-RPC / WebSocket]: ../../references/http-websocket-apis/index.md
@@ -89,18 +90,17 @@ Si la integración de una institución financiera con el XRP Ledger asume que el
**La forma correcta de procesar las transacciones de Pago entrantes es utilizar [el campo `delivered_amount` de los metadatos](#the-delivered_amount-field),** no el campo `Amount`. De este modo, una institución nunca se equivocará sobre cuanto recibe _realmente_.
-
### Pasos del escenario del Exploit
Para realizar un exploit a una institución financiera vulnerable, un actor malicioso puede hacer lo siguiente:
-1. El actor malicioso envía una transacción de Pago a la institución. Esta transacción tiene un campo `Amount` grande y tiene el flag de **`tfPartialPayment`** activado.
+1. El actor malicioso envía una transacción de Pago a la institución. Esta transacción tiene un campo `Amount` grande y tiene el flag de **`tfPartialPayment`** activado.
2. El pago parcial tiene éxito (código de resultado `tesSUCCESS`) pero en realidad entrega una cantidad muy pequeña de la divisa especificada.
3. La institución vulnerable lee el campo `Amount` sin mirar el campo `Flags` o el campo de metadatos `delivered_amount`.
4. La institutución vulnerable acredita al actor malicioso en un sistema externo, como el propio ledger de la institución, por el `Amount` completo, a pesar de recibir solo un `delivered_amount` pequeño en el XRP Ledger.
5. El actor malicioso retira tanto saldo como sea posible antes de que la institución vulnerable note la discrepancia.
- - Los actores maliciosos suelen preferir convertir el saldo a otra criptomoneda como Bitcoin, porque las transacciones de blockchain suelen ser irreversibles. Con un retiro a un sistema de moneda fiduciaria, la institución financiera podría revertir o cancelar la transacción varios días después de que se ejecute inicialmente.
- - En el caso de un exchange, el actor malicioso también puede retirar un saldo de XRP directamente de nuevo al XRP Ledger.
+ - Los actores maliciosos suelen preferir convertir el saldo a otra criptomoneda como Bitcoin, porque las transacciones de blockchain suelen ser irreversibles. Con un retiro a un sistema de moneda fiduciaria, la institución financiera podría revertir o cancelar la transacción varios días después de que se ejecute inicialmente.
+ - En el caso de un exchange, el actor malicioso también puede retirar un saldo de XRP directamente de nuevo al XRP Ledger.
En el caso de un comerciante, el orden de las operaciones es ligeramente diferente, pero el concepto es el mismo:
@@ -119,22 +119,21 @@ Utilizar [el campo `delivered_amount`](#the-delivered_amount-field) al procesar
- Añade chequeos adicionales a la lógica de tu negocio para procesar los retiros. Nunca proceses un retiro si el balance total que tienes en el XRP Ledger no coincide con tus activos y obligaciones esperados.
- Sigue las directrices "Know Your Customer" y verifica estrictamente las identidades de tus clientes. Puede que reconozcas y bloquees usuarios maliciosos de antemano, o emprender acciones legales contra el actor malicioso que genera exploits a tu sistema.
-
## Ver también
- **Herramientas:**
- - [Remitente de la transacción](/resources/dev-tools/tx-sender)
+ - [Remitente de la transacción](/resources/dev-tools/tx-sender)
- **Conceptos:**
- - [Transacciones](../transactions/index.md)
+ - [Transacciones](../transactions/index.md)
- **Tutoriales:**
- - [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md)
- - [Monitorear pagos recibidos con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
- - [Usar tipos de pagos especializados](../../tutorials/how-tos/use-specialized-payment-types/index.md)
- - [Listar XRP en un Exchange](../../use-cases/defi/list-xrp-as-an-exchange.md)
+ - [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md)
+ - [Monitorear pagos recibidos con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+ - [Usar tipos de pagos especializados](../../tutorials/how-tos/use-specialized-payment-types/index.md)
+ - [Listar XRP en un Exchange](../../use-cases/defi/list-xrp-as-an-exchange.md)
- **Referencias:**
- - [Transacción de Pago][]
- - [Metadatos de transacción](../../references/protocol/transactions/metadata.md)
- - [método account_tx][]
- - [método tx][]
+ - [Transacción de Pago][]
+ - [Metadatos de transacción](../../references/protocol/transactions/metadata.md)
+ - [método account_tx][]
+ - [método tx][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/payment-types/payment-channels.md b/@l10n/es-ES/docs/concepts/payment-types/payment-channels.md
index b55523560a..cea9067993 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/payment-channels.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/payment-channels.md
@@ -2,11 +2,12 @@
html: payment-channels.html
parent: payment-types.html
seo:
- description: Los canales de pago que activan pagos XRP asíncronos rápidos que pueden dividirse en incrementos muy pequeños y liquidarse más después.
+ description: Los canales de pago que activan pagos XRP asíncronos rápidos que pueden dividirse en incrementos muy pequeños y liquidarse más después.
labels:
- Canales de pago
- Smart Contracts
---
+
# Canales de pago
Los Canales de Pago son una función avanzada para enviar pagos de XRP "asíncronos" que pueden dividirse en incrementos muy pequeños y liquidarse más tarde.
@@ -15,7 +16,6 @@ El XRP para un canal de pago se reserva temporalmente. El remitente crea reclama
Debido a que las reclamaciones pueden verificarse individualmente pero liquidarse en bloque más adelante, los canales de pago hacen posible realizar transacciones a una velocidad limitada solo por la capacidad de los participantes para crear y verificar las firmas digitales de esas Reclamaciones. Este límite se basa principalmente en la velocidad del hardware de los participantes y la complejidad de los algoritmos de firma. Para obtener la máxima velocidad, utiliza firmas Ed25519, que son más rápidas que las firmas ECDSA secp256k1 predeterminadas del XRP Ledger. La investigación ha [demostrado la capacidad de crear más de 100.000 firmas Ed25519 por segundo y verificar más de 70.000 por segundo](https://ed25519.cr.yp.to/ed25519-20110926.pdf) en hardware estándar en 2011.
-
## ¿Por qué usar canales de pago?
El proceso de usar un canal de pago siempre implica dos partes, un pagador y un beneficiario. El pagador es una persona o institución que utiliza el XRP Ledger y es cliente del beneficiario. El beneficiario es una persona o empresa que recibe XRP como pago por bienes o servicios.
@@ -26,27 +26,25 @@ Los Canales de Pago no especifican intrínsecamente nada sobre lo que puedes com
- Cosas baratas, donde el coste de procesar una transacción es una parte no trivial del precio
- Cosas que normalmente se compran en bloque, donde la cantidad exacta deseada no se conoce de antemano
-
## Ciclo de vida de un canal de pago
El siguiente diagrama resume el ciclo de vida de un canal de pago:
-[{% inline-svg file="/docs/img/paychan-flow.svg" /%}](/docs/img/paychan-flow.svg "Diagrama de flujo de un canal de pago")
-
+[{% inline-svg file="/docs/img/paychan-flow.svg" /%}](/docs/img/paychan-flow.svg 'Diagrama de flujo de un canal de pago')
## Ver también
- **Conceptos relacionados:**
- - [Escrow](escrow.md), una función similar para pagos XRP condicionales de mayor valor y menor velocidad.
+ - [Escrow](escrow.md), una función similar para pagos XRP condicionales de mayor valor y menor velocidad.
- **Tutoriales y casos de uso:**
- - [Utilizar canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md), un tutorial que guía a través del proceso de utilizar un canal de pago.
- - [Abrir un canal de pago para activar una red de intercambio](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/open-a-payment-channel-to-enable-an-inter-exchange-network.md)
+ - [Utilizar canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md), un tutorial que guía a través del proceso de utilizar un canal de pago.
+ - [Abrir un canal de pago para activar una red de intercambio](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/open-a-payment-channel-to-enable-an-inter-exchange-network.md)
- **Referencias:**
- - [Método channel_authorize][]
- - [Método channel_verify][]
- - [Objeto PayChannel](../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)
- - [Transacción PaymentChannelClaim][]
- - [Transacción PaymentChannelCreate][]
- - [Transacción PaymentChannelFund][]
+ - [Método channel_authorize][]
+ - [Método channel_verify][]
+ - [Objeto PayChannel](../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)
+ - [Transacción PaymentChannelClaim][]
+ - [Transacción PaymentChannelCreate][]
+ - [Transacción PaymentChannelFund][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md b/@l10n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md
index 110e9bcb6e..fad21cedcc 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md
@@ -2,26 +2,27 @@
html: robustly-monitoring-for-payments.html
parent: payment-types.html
seo:
- description: Recomendaciones para monitorizar pagos entrantes de una variedad e posibles irregularidades.
+ description: Recomendaciones para monitorizar pagos entrantes de una variedad e posibles irregularidades.
labels:
- Tokens
---
+
# Monitoreo robusto de pagos
Para verificar robustamente los pagos entrantes, los emisores deberían hacer lo siguiente:
-* Mantener un registro de la transacción y el ledger más recientemente procesados. De esta manera, si pierdes temporalmente la conectividad, sabrás hasta dónde retroceder.
-* Verificar el código de resultado de cada pago entrante. Algunos pagos ingresan al ledger para cobrar una tarifa contra el spam, incluso si fallan. Solo las transacciones con el código de resultado `tesSUCCESS` pueden cambiar saldos que no sean de XRP. Solo las transacciones de un ledger validado son definitivas.
-* Mirar los [pagos parciales](partial-payments.md). Los pagos con el flag de pago parcial activado pueden ser condierados "exitosos" si se entrega cualquier cantidad distinta a cero, incluso cantidades minúsculas.
- * Comprobar la transacción en busca del [campo `delivered_amount`](partial-payments.md#el-campo-delivered_amount). Si está presente, el campo indica cuanto dinero _realmente_ se envió a la dirección `Destination`.
- * En xrpl.js, puedes usar el [método `xrpl.getBalanceChanges()`](https://js.xrpl.org/modules.html#getBalanceChanges) para ver cuánto recibió cada dirección. En algunos casos, esto puede dividirse en varias partes en diferentes líneas de confianza (trustlines).
-* Algunas transacciones cambian tus balances sin ser pagos directos hacia o desde una de tus direcciones.
+- Mantener un registro de la transacción y el ledger más recientemente procesados. De esta manera, si pierdes temporalmente la conectividad, sabrás hasta dónde retroceder.
+- Verificar el código de resultado de cada pago entrante. Algunos pagos ingresan al ledger para cobrar una tarifa contra el spam, incluso si fallan. Solo las transacciones con el código de resultado `tesSUCCESS` pueden cambiar saldos que no sean de XRP. Solo las transacciones de un ledger validado son definitivas.
+- Mirar los [pagos parciales](partial-payments.md). Los pagos con el flag de pago parcial activado pueden ser condierados "exitosos" si se entrega cualquier cantidad distinta a cero, incluso cantidades minúsculas.
+ - Comprobar la transacción en busca del [campo `delivered_amount`](partial-payments.md#el-campo-delivered_amount). Si está presente, el campo indica cuanto dinero _realmente_ se envió a la dirección `Destination`.
+ - En xrpl.js, puedes usar el [método `xrpl.getBalanceChanges()`](https://js.xrpl.org/modules.html#getBalanceChanges) para ver cuánto recibió cada dirección. En algunos casos, esto puede dividirse en varias partes en diferentes líneas de confianza (trustlines).
+- Algunas transacciones cambian tus balances sin ser pagos directos hacia o desde una de tus direcciones.
Para simplificar las cosas para tus clientes, te recomendamos aceptar pagos tanto en tu dirección operacional como en tus direcciones de emisoras.
Como precaución adicional, te recomendamos comparar los balances de tus direcciones emisoras con los fondos de garantía en tu sistema de contabilidad interna en cada nueva versión del ledger del XRP Ledger. Los saldos negativos de la dirección emisora deben coincidir con los activos que has asignado al XRP Ledger fuera de la red. Si ambos no coinciden, deberías suspender el procesamiento de pagos hacia y desde el XRP Ledger hasta que hayas resuelto la discrepancia.
-* Utiliza el método `gateway_balances` para comprobar tus balances.
-* Si tienes un coste de transferencia (transfer fee) establecido, entonces tus obligaciones dentro del XRP Ledger disminuyen ligeramente cada vez que otras direcciones del XRP Ledger transfieran tus tokens entre sí.
+- Utiliza el método `gateway_balances` para comprobar tus balances.
+- Si tienes un coste de transferencia (transfer fee) establecido, entonces tus obligaciones dentro del XRP Ledger disminuyen ligeramente cada vez que otras direcciones del XRP Ledger transfieran tus tokens entre sí.
Para más detalles en cómo se leen los detalles de transacciones entrantes, visita [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md).
diff --git a/@l10n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md b/@l10n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md
index 453abbf78f..48b026f602 100644
--- a/@l10n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md
+++ b/@l10n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md
@@ -2,10 +2,11 @@
html: sending-payments-to-customers.html
parent: payment-types.html
seo:
- description: Construye los pagos con cuidado para frustrar a los actores maliciosos.
+ description: Construye los pagos con cuidado para frustrar a los actores maliciosos.
labels:
- Tokens
---
+
# Enviar pagos a clientes
Cuando construyes un sistema automatizado para enviar pagos al XRP Ledger para tus clientes, debes asegurarte de que construyes los pagos cuidadosamente. Los actores maliciosos están constantemente tratando de encontrar formas de engañar a un sistema para que les pague más dinero del que debería.
diff --git a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/autobridging.md b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/autobridging.md
index 79ba7e1de0..10c3f7411e 100644
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/autobridging.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/autobridging.md
@@ -2,14 +2,15 @@
html: autobridging.html
parent: decentralized-exchange.html
seo:
- description: El puente automático conecta automáticamente los libros de órdenes utilizando XRP como intermediario cuando reduce los costes.
+ description: El puente automático conecta automáticamente los libros de órdenes utilizando XRP como intermediario cuando reduce los costes.
labels:
- XRP
- Exchange Descentralizado
---
+
# Puente automático
-Cualquier [Oferta](offers.md) en el [exchange descentralizado](index.md) del XRP Ledger que intercambie dos tokens podría potencialmente utilizar XRP como moneda intermediaria en un libro de órdenes sintético. Esto se debe al _puente automático_, que sirve para mejorar la liquidez en todos los pares de activos utilizando XRP cuando es más barato que intercambiar directamente. Esto funciona debido a la naturaleza de XRP como criptomoneda nativa del XRP Ledger. La ejecución de la oferta puede utilizar una combinación de ofertas directas y ofertas auto-puenteadas para lograr la mejor tasa de cambio total.
+Cualquier [Oferta](offers.md) en el [exchange descentralizado](index.md) del XRP Ledger que intercambie dos tokens podría potencialmente utilizar XRP como moneda intermediaria en un libro de órdenes sintético. Esto se debe al _puente automático_, que sirve para mejorar la liquidez en todos los pares de activos utilizando XRP cuando es más barato que intercambiar directamente. Esto funciona debido a la naturaleza de XRP como criptomoneda nativa del XRP Ledger. La ejecución de la oferta puede utilizar una combinación de ofertas directas y ofertas auto-puenteadas para lograr la mejor tasa de cambio total.
Ejemplo: _Anita crea una oferta para vender GBP y comprar BRL. Ella podría encontrar que este mercado poco común tiene pocas ofertas. Hay una oferta con una buena tasa, pero tiene una cantidad insuficiente para satisfacer el intercambio de Anita. Sin embargo, tanto GBP como BRL tienen mercados activos y competitivos para XRP. El sistema de puente automático del XRP Ledger encuentra una forma de completar la oferta de Anita comprando XRP con GBP de un trader, luego vendiendo el XRP a otro trader para comprar BRL. Anita obtiene automáticamente la mejor tasa posible combinando la pequeña oferta en el mercado directo de GBP:BRL con las mejores tasas compuestas creadas emparejando las ofertas GBP:XRP y XRP:BRL._
diff --git a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
index 5adf0ada89..f8b2e21093 100644
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
@@ -2,13 +2,14 @@
html: automated-market-makers.html
parent: decentralized-exchange.html
seo:
- title: ¿Qué es un Automated Market Maker (AMM)?
- description: Los Automated Market Makers (AMMs) son una parte esencial de las criptomonedas, proveen liquidez entre dos pares de activos. Aprende más sobre AMMs y el XRP Ledger.
+ title: ¿Qué es un Automated Market Maker (AMM)?
+ description: Los Automated Market Makers (AMMs) son una parte esencial de las criptomonedas, proveen liquidez entre dos pares de activos. Aprende más sobre AMMs y el XRP Ledger.
labels:
- XRP
- Exchange Descentralizado
- AMM
---
+
# ¿Qué es un Automated Market Maker (AMM)?
_(Requiere la [enmienda AMM][] XLS-30)_
@@ -43,9 +44,10 @@ Para evitar el mal uso, se aplican algunas restricciones a los activos utilizado
- Si el activo es un token cuyo emisor utiliza [Authorized Trust Lines](../fungible-tokens/authorized-trust-lines.md), el creador del AMM debe estar autorizado para poseer esos tokens. Solo los usuarios cuyas líneas de confianza (trustlines) estén autorizadas pueden depositar ese token en el AMM o retirarlo; sin embargo, los usuarios aún pueden depositar o retirar el otro activo.
- Si la [enmienda Clawback][] está habilitada, el emisor del token no debe haber habilitado la capacidad de recuperar sus tokens.
-
## Tokens LP
+
+
Quien crea el AMM se convierte en el primer proveedor de liquidez y recibe Tokens LP que representan el 100% de la propiedad de los activos en el pool del AMM. Pueden canjear algunos o todos esos Tokens LP para retirar activos del AMM en proporción a las cantidades actualmente allí. (Las proporciones cambian con el tiempo a medida que las personas comercian contra el AMM). El AMM no cobra una tarifa al retirar ambos activos.
Por ejemplo, si creaste un AMM con 5 ETH y 5 USD, y luego alguien cambió 1.26 USD por 1 ETH, el pool ahora tiene 4 ETH y 6.26 USD en él. Puedes gastar la mitad de tus Tokens LP para retirar 2 ETH y 3.13 USD.
@@ -60,7 +62,6 @@ El AMM está diseñado de manera que el pool de activos de un AMM esté vacío s
Los Tokens LP utilizan un tipo especial de código de moneda en el formato hexadecimal de 160 bits ["no estándar"](../../../references/protocol/data-types/currency-formats.md#nonstandard-currency-codes). Estos códigos tienen los primeros 8 bits `0x03`. El resto del código es un hash SHA-512, truncado a los primeros 152 bits, de los códigos de moneda de los dos activos y sus emisores. (Los activos se colocan en un "orden canónico" con el par de moneda+emisor numéricamente inferior primero). Como resultado, los Tokens LP para un par de activos dado de un AMM tienen un código de moneda predecible y consistente.
-
## Tarifas de intercambio
Las tarifas de intercambio son una fuente de ingresos pasivos para los proveedores de liquidez, y compensan el riesgo cambiario de permitir que otros intercambien activos del pool. Las tarifas de intercambio se pagan al AMM, no directamente a los proveedores de liquidez, pero estos se benefician porque sus Tokens LP se pueden canjear por un porcentaje del pool del AMM.
@@ -75,7 +76,6 @@ A diferencia de cualquier Automated Market Maker anterior, el diseño de AMM del
Con cualquier AMM, cuando el precio de sus activos cambia significativamente en los mercados externos, los traders pueden usar arbitraje para obtener beneficios del AMM, lo que resulta en una pérdida para los proveedores de liquidez. El mecanismo de subasta tiene como objetivo devolver más de ese valor a los proveedores de liquidez y llevar los precios del AMM más rápidamente de vuelta al equilibrio con los mercados externos.
-
## Representación en el Ledger
En los datos de estado del ledger, un AMM consiste en múltiples [entradas de ledger](../../../references/protocol/ledger-data/ledger-entry-types/index.md):
@@ -84,13 +84,12 @@ En los datos de estado del ledger, un AMM consiste en múltiples [entradas de le
- Una [entrada AccountRoot][] especial que emite Tokens LP del AMM, y tiene XRP del AMM (si lo tiene).
- La dirección de esta AccountRoot se elige de forma algo aleatoria cuando se crea el AMM, y es diferente si el AMM se elimina y se vuelve a crear. Esto puede prevenir que las personas financien la cuenta AMM con XRP excesivo por adelantado.
+ La dirección de esta AccountRoot se elige de forma algo aleatoria cuando se crea el AMM, y es diferente si el AMM se elimina y se vuelve a crear. Esto puede prevenir que las personas financien la cuenta AMM con XRP excesivo por adelantado.
- Las [Trust lines](../fungible-tokens/index.md) a la cuenta especial AMM para los tokens en el pool del AMM.
Estas entradas de ledger no son propiedad de ninguna cuenta, por lo que el [requisito de reserva](../../accounts/reserves.md) no se aplica a ellas. Sin embargo, para prevenir el spam, la transacción para crear un AMM tiene un [coste de transacción](../../transactions/transaction-cost.md) especial que requiere que el remitente queme una cantidad de XRP mayor de lo habitual.
-
## Eliminación
Un AMM se elimina cuando una [transacción AMMWithdraw][] retira todos los activos de su pool. Esto solo ocurre canjeando todos los Tokens LP pendientes del AMM. La eliminación del AMM incluye la eliminación de todas las entradas del ledger asociadas con él, como:
@@ -102,7 +101,7 @@ Un AMM se elimina cuando una [transacción AMMWithdraw][] retira todos los activ
Si hay más de 512 trust lines enlazadas a la cuenta del AMM cuando se eliminase, el proceso de retiro tiene éxito y elimina tantas trust lines como puede, pero deja el AMM en el ledger sin activos en su pool.
-Mientras un AMM no tenga activos en su pool, cualquiera puede eliminarlo enviando una [transacción AMMDelete][]; si el número restante de líneas de confianza sigue siendo mayor que el límite, pueden ser necesarias múltiples transacciones AMMDelete para eliminar completamente el AMM. Alternativamente, cualquier persona puede realizar un [depósito especial](../../../references/protocol/transactions/types/ammdeposit.md#empty-amm-special-case) para financiar el AMM como si fuera nuevo.
+Mientras un AMM no tenga activos en su pool, cualquiera puede eliminarlo enviando una [transacción AMMDelete][]; si el número restante de líneas de confianza sigue siendo mayor que el límite, pueden ser necesarias múltiples transacciones AMMDelete para eliminar completamente el AMM. Alternativamente, cualquier persona puede realizar un [depósito especial](../../../references/protocol/transactions/types/ammdeposit.md#empty-amm-special-case) para financiar el AMM como si fuera nuevo.
No hay reembolso o incentivo para eliminar un AMM vacío.
diff --git a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/index.md b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/index.md
index 778b5d1a5f..8bd10aff5d 100644
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/index.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/index.md
@@ -4,10 +4,11 @@ parent: tokens.html
metadata:
indexPage: true
seo:
- description: El XRP Ledger contiene un exchange completamente funcional donde los usuarios pueden intercambiar tokens por XRP o entre sí.
+ description: El XRP Ledger contiene un exchange completamente funcional donde los usuarios pueden intercambiar tokens por XRP o entre sí.
targets:
- en
---
+
# Exchange descentralizado
El XRP Ledger posiblemente tenga el _exchange descentralizado_ más antiguo del mundo (a veces abreviado como "DEX"), operando de manera continua desde el lanzamiento del XRP Ledger en 2012. Este exchange permite a los usuarios comprar y vender [tokens](../index.md) por XRP u otros tokens, con [costes](../../transactions/fees.md) mínimos cargados a la red misma (no pagados a ninguna parte).
@@ -18,7 +19,7 @@ El XRP Ledger posiblemente tenga el _exchange descentralizado_ más antiguo del
El exchange descentralizado del XRP Ledger consta de un número ilimitado de pares de divisas, rastreados según la demanda cuando los usuarios realizan intercambios. Un par de divisas puede consistir en XRP y un token o dos tokens diferentes; los tokens siempre se identifican por la combinación de un emisor y un código de moneda. Es posible comerciar entre dos tokens con el mismo código de moneda y diferentes emisores, o el mismo emisor y diferentes códigos de moneda.
-Como con todos los cambios en el XRP Ledger, necesitas enviar una [transacción](../../transactions/index.md) para realizar un intercambio. Un intercambio en el XRP Ledger se conoce como Oferta u [Offer](offers.md). Una Oferta es efectivamente una [_Orden límite_](https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order) para comprar o vender una cantidad específica de una moneda (XRP o un token) por una cantidad específica de otra. Cuando la red ejecuta una Oferta, si hay otras Ofertas coincidentes para el mismo par de divisas, estas se consumen comenzando con la mejor tasa de cambio primero.
+Como con todos los cambios en el XRP Ledger, necesitas enviar una [transacción](../../transactions/index.md) para realizar un intercambio. Un intercambio en el XRP Ledger se conoce como Oferta u [Offer](offers.md). Una Oferta es efectivamente una [_Orden límite_]() para comprar o vender una cantidad específica de una moneda (XRP o un token) por una cantidad específica de otra. Cuando la red ejecuta una Oferta, si hay otras Ofertas coincidentes para el mismo par de divisas, estas se consumen comenzando con la mejor tasa de cambio primero.
Una Oferta puede llenarse completamente o parcialmente; si no se llena completamente de inmediato, se convierte en un objeto de Oferta pasiva en el ledger para la cantidad restante. Más adelante, otras Ofertas o [pagos entre divisas](../../payment-types/cross-currency-payments.md) pueden coincidir y consumir la Oferta. Debido a esto, las Ofertas pueden ejecutarse a un mejor precio que el solicitado inicialmente, o exactamente al tipo de cambio indicado más tarde (excepto por diferencias menores para tener en cuenta el redondeo).
@@ -28,23 +29,22 @@ Al comerciar con dos tokens, el [puente automático](autobridging.md) mejora las
### Ejemplo de intercambio
-[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.svg" /%}](/docs/img/decentralized-exchange-example-trade.svg "Diagrama: Oferta parcialmente completada para comprar un token con XRP.")
+[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.svg" /%}](/docs/img/decentralized-exchange-example-trade.svg 'Diagrama: Oferta parcialmente completada para comprar un token con XRP.')
El diagrama anterior muestra un ejemplo de intercambio en el exchange descentralizado. En este ejemplo, un trader llamado Tran coloca una Oferta para comprar 100 tokens con el código de moneda FOO emitido por un negocio ficticio llamado WayGate. (Por brevedad, "FOO.WayGate" se refiere a estos tokens.) Tran especifica que está dispuesto a gastar hasta 1000 XRP en total. Cuando la transacción de Tran es procesada, ocurren las siguientes cosas:
1. La red calcula la tasa de cambio de la Oferta de Tran, dividiendo la cantidad a comprar por la cantidad a pagar.
-0. La red encuentra el libro de órdenes para el reverso de la Oferta de Tran: en este caso, eso significa el libro de órdenes para vender FOO.WayGate y comprar XRP. Este libro de órdenes ya tiene varias Ofertas existentes de otros traders para diferentes cantidades y tasas de cambio.
-0. La Oferta de Tran "consume" Ofertas coincidentes, comenzando con la mejor tasa de cambio y trabajando hacia abajo, hasta que la Oferta de Tran se haya llenado por completo o no haya más Ofertas cuya tasa de cambio sea igual o mejor que la tasa especificada en la Oferta de Tran. En este ejemplo, solo hay disponibles 22 FOO.WayGate a la tasa solicitada o mejor. Las Ofertas consumidas se eliminan del libro de órdenes.
-0. Tran recibe la cantidad de FOO.WayGate que el intercambio pudo adquirir, de los varios traders que previamente habían colocado órdenes para venderlo. Estos tokens van a la [trust line](../fungible-tokens/index.md) de Tran a WayGate para FOO. (Si Tran no tenía esa trust line previamente, se crea automáticamente una).
-0. A cambio, esos traders reciben XRP de Tran de acuerdo con sus tasas de cambio declaradas.
-0. La red calcula el resto de la Oferta de Tran: dado que la Oferta original era para comprar 100 FOO.WayGate y hasta ahora Tran ha recibido 22, el resto es de 78 FOO.WayGate. Usando la tasa de cambio original, eso significa que el resto de la Oferta de Tran ahora es comprar 78 FOO.WayGate por 780 XRP.
-0. El "resto" resultante se coloca en el libro de órdenes para intercambios en la misma dirección que la de Tran: vendiendo XRP y comprando FOO.WayGate.
+2. La red encuentra el libro de órdenes para el reverso de la Oferta de Tran: en este caso, eso significa el libro de órdenes para vender FOO.WayGate y comprar XRP. Este libro de órdenes ya tiene varias Ofertas existentes de otros traders para diferentes cantidades y tasas de cambio.
+3. La Oferta de Tran "consume" Ofertas coincidentes, comenzando con la mejor tasa de cambio y trabajando hacia abajo, hasta que la Oferta de Tran se haya llenado por completo o no haya más Ofertas cuya tasa de cambio sea igual o mejor que la tasa especificada en la Oferta de Tran. En este ejemplo, solo hay disponibles 22 FOO.WayGate a la tasa solicitada o mejor. Las Ofertas consumidas se eliminan del libro de órdenes.
+4. Tran recibe la cantidad de FOO.WayGate que el intercambio pudo adquirir, de los varios traders que previamente habían colocado órdenes para venderlo. Estos tokens van a la [trust line](../fungible-tokens/index.md) de Tran a WayGate para FOO. (Si Tran no tenía esa trust line previamente, se crea automáticamente una).
+5. A cambio, esos traders reciben XRP de Tran de acuerdo con sus tasas de cambio declaradas.
+6. La red calcula el resto de la Oferta de Tran: dado que la Oferta original era para comprar 100 FOO.WayGate y hasta ahora Tran ha recibido 22, el resto es de 78 FOO.WayGate. Usando la tasa de cambio original, eso significa que el resto de la Oferta de Tran ahora es comprar 78 FOO.WayGate por 780 XRP.
+7. El "resto" resultante se coloca en el libro de órdenes para intercambios en la misma dirección que la de Tran: vendiendo XRP y comprando FOO.WayGate.
Las transacciones posteriores, incluidas aquellas ejecutadas inmediatamente después de las de Tran en el _mismo_ ledger, utilizan los libros de órdenes actualizados para sus intercambios, por lo que pueden consumir parte o toda la Oferta de Tran hasta que se llene por completo o Tran la cancele.
**Nota**: El orden canónico en el que las transacciones se ejecutan cuando se cierra y valida un ledger no es el mismo que el orden en el que se enviaron esas transacciones. Cuando varias transacciones afectan al mismo libro de órdenes en el mismo ledger, los resultados finales de esas transacciones pueden ser muy diferentes a los resultados tentativos calculados en el momento del envío de la transacción. Para obtener más detalles sobre cuándo los resultados de las transacciones son o no finales, consulta [Finalidad de resultados](../../transactions/finality-of-results/index.md).
-
## Limitaciones
El exchange descentralizado está diseñado con las siguientes limitaciones:
@@ -58,17 +58,16 @@ Como sistema descentralizado, el XRP Ledger no tiene información sobre las pers
## Ver también
- **Conceptos:**
- - Ver [Ofetas](offers.md) para obtener detalles sobre cómo funcionan los intercambios en el XRP Ledger.
- - Ver [Tokens](../index.md) para obtener una descripción general de cómo se pueden representar diversos tipos de valor en el XRP Ledger.
+ - Ver [Ofetas](offers.md) para obtener detalles sobre cómo funcionan los intercambios en el XRP Ledger.
+ - Ver [Tokens](../index.md) para obtener una descripción general de cómo se pueden representar diversos tipos de valor en el XRP Ledger.
- **Referencias:**
- - [método account_offers][] para buscar Ofertas creadas por una cuenta
- - [método book_offers][] para buscar Ofertas de compra o venta según un par de divisas dado
- - [transacción OfferCreate][] para crear una Oferta nueva o reemplazar una Oferta existente
- - [transacción OfferCancel][] para cancelar una Oferta existente
- - [objeto Offer][] para la estructura de datos de las Ofertas pasivas en el ledger
- - [objeto DirectoryNode][] para la estructura de datos que sigue todas las Ofertas para un par de divisas y tarifa de intercambio dados.
+ - [método account_offers][] para buscar Ofertas creadas por una cuenta
+ - [método book_offers][] para buscar Ofertas de compra o venta según un par de divisas dado
+ - [transacción OfferCreate][] para crear una Oferta nueva o reemplazar una Oferta existente
+ - [transacción OfferCancel][] para cancelar una Oferta existente
+ - [objeto Offer][] para la estructura de datos de las Ofertas pasivas en el ledger
+ - [objeto DirectoryNode][] para la estructura de datos que sigue todas las Ofertas para un par de divisas y tarifa de intercambio dados.
{% raw-partial file="/docs/_snippets/common-links.md" /%}
-
{% child-pages /%}
diff --git a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/offers.md b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/offers.md
index 3b00dfb497..ef1320a013 100644
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/offers.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/offers.md
@@ -2,10 +2,11 @@
html: offers.html
parent: decentralized-exchange.html
seo:
- description: Las ofertas son la forma de órdenes de comercio de divisas del XRP Ledger. Comprende su ciclo de vida y propiedades.
+ description: Las ofertas son la forma de órdenes de comercio de divisas del XRP Ledger. Comprende su ciclo de vida y propiedades.
labels:
- Exchange Descentralizado
---
+
# Ofertas
En el [exchange descentralizado](index.md) del XRP Ledger, las órdenes de intercambio se llaman "Ofertas". Las Ofertas pueden intercambiar XRP con [tokens](../index.md), o tokens por otros tokens, incluyendo tokens con el mismo código de moneda pero diferentes emisores. (Los tokens con el mismo código pero diferentes emisores también a veces pueden intercambiarse a través de [rippling](../fungible-tokens/rippling.md).)
@@ -29,7 +30,6 @@ Mientras tengas una Oferta en el ledger, se aparta parte de tu XRP hacia la [res
- Una Oferta **Completar o Cancelar** no se coloca en el ledger, _y_ se cancela si la cantidad total no se completa cuando se ejecuta inicialmente. Esto es similar a "Inmediata o Cancelar", excepto que _no puede_ completarse parcialmente.
- Una Oferta **Pasiva** no consume Ofertas coincidentes que tengan el mismo tipo de cambio (en la otra dirección), y en su lugar se coloca directamente en el ledger. Puedes usar esto para crear un peg exacto entre dos activos. Las Ofertas Pasivas aún consumen otras Ofertas que tienen un tipo de cambio _mejor_ en la otra dirección.
-
### Requisitos de financiación
Cuando intentas realizar una Oferta, la transacción se rechaza como "no financiada" si no tienes al menos parte del activo que la operación vendería. Más específicamente:
@@ -50,11 +50,11 @@ Si colocas una Oferta que cruza alguna de tus propias Ofertas que existen en el
Es posible que una Oferta se vuelva temporal o permanentemente _no financiada_ en los siguientes casos:
- Si el propietario ya no tiene ningún activo de venta.
- - La Oferta se vuelve financiada nuevamente cuando el propietario obtiene más de ese activo.
+ - La Oferta se vuelve financiada nuevamente cuando el propietario obtiene más de ese activo.
- Si el activo en venta es un token en una [trust line congelada](../fungible-tokens/freezes.md).
- - La Oferta se vuelve financiada nuevamente cuando la trust line ya no está congelada.
+ - La Oferta se vuelve financiada nuevamente cuando la trust line ya no está congelada.
- Si la Oferta necesita crear una nueva trust line, pero el dueño no tiene suficiente XRP para el aumento de la [reserva](../../accounts/reserves.md). (Ver [Ofertas y confianza](#offers-and-trust).)
- - La oferta vuelve a estar financiada cuando el propietario obtiene más XRP, o los requisitos de reserva disminuyen.
+ - La oferta vuelve a estar financiada cuando el propietario obtiene más XRP, o los requisitos de reserva disminuyen.
- Si la Oferta ha expirado. (Ver [Expiración de ofertas](#offer-expiration).)
Una Oferta no financiada permanece en el ledger hasta que una transacción la elimine. Las formas en que una Oferta puede ser eliminada del ledger incluyen:
@@ -63,7 +63,7 @@ Una Oferta no financiada permanece en el ledger hasta que una transacción la el
- El propietario cancela explicitamente la Oferta.
- El propietario cancela implícitamente la Oferta enviando una nueva Oferta que la cruza.
- La Oferta es encontrada sin financiar o expirada durante el procesamiento de la transacción. Normalmente esto significa que otra Oferta intentó consumirla y no pudo hacerlo.
- - Esto incluye casos donde la cantidad restante puede ser pagada mediante la Oferta redondeada a cero.
+ - Esto incluye casos donde la cantidad restante puede ser pagada mediante la Oferta redondeada a cero.
### Seguimiento de ofertas no financiadas
@@ -71,7 +71,6 @@ Seguir el estado de financiación de todas las Ofertas puede ser computacionalme
Una aplicación de cliente puede seguir localmente el estado de financiación de las Ofertas. Para hacerlo, primero recupera un libro de órdenes utilizando el [método book_offers][] y verifica el campo `taker_gets_funded` de las Ofertas. Luego, [suscríbete](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md) al flujo de `transactions` y observa los metadatos de transacción para ver qué Ofertas se modifican.
-
## Ofertas y confianza
Los valores límite de las [trust lines](../fungible-tokens/index.md) no afectan a las Ofertas. En otras palabras, puedes usar una Oferta para adquirir más de la cantidad máxima en la que confías en un emisor.
@@ -80,13 +79,11 @@ Sin embargo, mantener tokens aún requiere una trust line con el emisor. Cuando
Los límites de la trust line te protegen de recibir más de un token como pago de lo que deseas. Las Ofertas pueden superar esos límites porque son una declaración explícita de cuánto del token deseas.
-
## Preferencia de Oferta
Las Ofertas existentes se agrupan por tipo de cambio, que se mide como la relación entre `TakerGets` y `TakerPays`. Las Ofertas con un tipo de cambio más alto se toman preferentemente. (Es decir, la persona que acepta la oferta recibe tanto como sea posible por la cantidad de moneda que paga). Las Ofertas con el mismo tipo de cambio se toman en función de cuál se colocó primero.
-Cuando las Ofertas se ejecutan en el mismo bloque del ledger, el orden en que se ejecutan se determina por el [orden canónico](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Código fuente: Ordenación de transacciones") en el que las transacciones fueron [aplicadas en el ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Código fuente: Aplicando transacciones"). Este comportamiento está diseñado para ser determinista, eficiente y difícil de manipular.
-
+Cuando las Ofertas se ejecutan en el mismo bloque del ledger, el orden en que se ejecutan se determina por el [orden canónico](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp 'Código fuente: Ordenación de transacciones') en el que las transacciones fueron [aplicadas en el ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 'Código fuente: Aplicando transacciones'). Este comportamiento está diseñado para ser determinista, eficiente y difícil de manipular.
## Caducidad de la oferta
@@ -98,17 +95,16 @@ Esto es una consecuencia de cómo la red alcanza un acuerdo. Para que toda la re
**Nota:** Las Ofertas caducadas permanecen en los datos del ledger hasta que una transacción las elimine. Hasta entonces, pueden continuar apareciendo en los datos recuperados a través de la API (por ejemplo, utilizando el [método ledger_entry][]). Las transacciones eliminan automáticamente cualquier Oferta caducada y no financiada que encuentren, generalmente mientras ejecutan Ofertas o pagos de monedas cruzadas que las hubieran igualado o cancelado. La reserva del propietario asociada con una Oferta solo vuelve a estar disponible cuando la Oferta se elimina realmente.
-
## Ver también
- **Conceptos:**
- - [Tokens](../index.md)
- - [Paths](../fungible-tokens/paths.md)
+ - [Tokens](../index.md)
+ - [Paths](../fungible-tokens/paths.md)
- **Referencias:**
- - [método account_offers][]
- - [método book_offers][]
- - [transacción OfferCreate][]
- - [transacción OfferCancel][]
- - [Objeto Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
+ - [método account_offers][]
+ - [método book_offers][]
+ - [transacción OfferCreate][]
+ - [transacción OfferCancel][]
+ - [Objeto Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/ticksize.md b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/ticksize.md
index f993936a12..75c1291ace 100644
--- a/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/ticksize.md
+++ b/@l10n/es-ES/docs/concepts/tokens/decentralized-exchange/ticksize.md
@@ -2,11 +2,12 @@
html: ticksize.html
parent: decentralized-exchange.html
seo:
- description: Los emisores pueden establecer tamaños de ticks personalizados para las monedas para reducir la rotación de libros de pedidos por diferencias minúsculas en los tipos de cambio.
+ description: Los emisores pueden establecer tamaños de ticks personalizados para las monedas para reducir la rotación de libros de pedidos por diferencias minúsculas en los tipos de cambio.
labels:
- Exchange Descentralizado
- Tokens
---
+
# Tamaño de Tick
Cuando se coloca una Oferta en un libro de órdenes, su tasa de cambio se trunca en base a los valores de `TickSize` establecidos por los emisores de las monedas involucradas en la Oferta. Cuando se negocia XRP y un token, se aplica el `TickSize` del emisor del token. Cuando se negocian dos tokens, la Oferta utiliza el valor de `TickSize` más pequeño (es decir, el que tiene menos dígitos significativos). Si ninguno de los tokens tiene un `TickSize` establecido, se aplica el comportamiento predeterminado.
@@ -21,8 +22,8 @@ Cuando un emisor habilita, deshabilita o cambia el `TickSize`, las Ofertas que s
- [Dev Blog: Introducción a la enmienda TickSize](https://xrpl.org/blog/2017/ticksize-voting.html#ticksize-amendment-overview)
- **Referencias:**
- - [transacción AccountSet][]
- - [método book_offers][]
- - [transacción OfferCreate][]
+ - [transacción AccountSet][]
+ - [método book_offers][]
+ - [transacción OfferCreate][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/introduction/crypto-wallets.md b/@l10n/es-ES/docs/introduction/crypto-wallets.md
index 3c5948295f..098207fadf 100644
--- a/@l10n/es-ES/docs/introduction/crypto-wallets.md
+++ b/@l10n/es-ES/docs/introduction/crypto-wallets.md
@@ -2,15 +2,15 @@
html: crypto-wallets.html
parent: intro-to-xrpl.html
seo:
- description: Las carteras brindan una forma conveniente de administrar tu XRP en el XRP Ledger.
+ description: Las carteras brindan una forma conveniente de administrar tu XRP en el XRP Ledger.
labels:
- Blockchain
---
+
# Carteras cripto
Las carteras cripto brindan una forma de administrar tu cuenta y tus fondos en el XRP Ledger. Hay muchas carteras para elegir. Al final, elegir la cartera adecuada se reduce a tus necesidades y a tus gustos al trabajar con XRP.
-
## Carteras con custodia vs carteras sin custodia
Un factor importante cuando se elige una cartera es si se desea que sea una cartera con custodia o sin custodia.
@@ -29,7 +29,6 @@ Las carteras sin custodia te permiten tener más libertad. Como estás interactu
Tanto los usuarios de carteras con custodia como los usuarios de carteras sin custodia deben protegerse de usuarios malintencionados que podrían intentar robar tus fondos. Con una cartera con custodia, debes administrar tu nombre de usuario y contraseña en la app o en el sitio web; en una cartera sin custodia, tienes que administrar las claves secretas (secrect keys) de tu cuenta en el libro contable (ledger). En ambos casos, las prácticas de seguridad propias del proveedor de la cartera también son importantes para protegerte de vulnerabilidades como ataques a la cadena de suministro, donde un atacante carga código malicioso en la cartera a través de actualizaciones o dependencias. Sin embargo, las carteras con custodia pueden ser un objetivo mayor para los atacantes, ya que tienen acceso inmediato a los fondos de múltiples usuarios.
-
## Carteras de software vs Carteras de hardware
Otro factor decisivo a la hora de elegir una cartera es elegir entre una cartera de hardware o de software.
@@ -40,10 +39,8 @@ Las carteras de hardware son dispositivos físicos que almacenan tus claves priv
Las carteras de software por el otro lado, son completamente digitales. Mientras esto las hace mucho más fáciles, también las convierte en el método menos seguro de los dos, pero generalmente vienen con funciones adicionales para mejorar la experiencia. Como última instancia, la decisión entre las dos dependerá de tu nivel de comidad y de lo importante que sea para ti la facilidad de uso.
-
## Crear tu propia cartera
El XRP Ledger es un proyecto de código abierto con librerías de cliente y métodos API disponibles públicamente. Si bien técnicamente se puede interactuar con el ledger utilizando herramientas HTTP/WebSocket, no es práctico para el uso del día a día. Puedes crear tu propia cartera para interactuar con el ledger, pero necesitarás entender exáctamente cómo funcionan las cuentas, transacciones y el ledger juntas antes de comprometerte con esta opción.
-
Siguiente: [Transacciones y peticiones](transactions-and-requests.md)
diff --git a/@l10n/es-ES/docs/introduction/index.md b/@l10n/es-ES/docs/introduction/index.md
index 0bd34dd9e2..19d389bce3 100644
--- a/@l10n/es-ES/docs/introduction/index.md
+++ b/@l10n/es-ES/docs/introduction/index.md
@@ -5,8 +5,9 @@ metadata:
indexPage: true
top_nav_grouping: Article Types
---
+
# Introducción
-El XRP Ledger es una blockchain que permanentemente registra transacciones digitales de tokens entre cuentas. Las secciones de abajo amplian los conceptos introducidos en esa frase.
+El XRP Ledger es una blockchain que permanentemente registra transacciones digitales de tokens entre cuentas. Las secciones de abajo amplian los conceptos introducidos en esa frase.
{% child-pages /%}
diff --git a/@l10n/es-ES/docs/introduction/software-ecosystem.md b/@l10n/es-ES/docs/introduction/software-ecosystem.md
index dc5db67d64..f466595f67 100644
--- a/@l10n/es-ES/docs/introduction/software-ecosystem.md
+++ b/@l10n/es-ES/docs/introduction/software-ecosystem.md
@@ -2,10 +2,11 @@
html: software-ecosystem.html
parent: introduction.html
seo:
- description: Obtén una descripción general de qué es el software XRP Ledger disponible y como funciona en conjunto.
+ description: Obtén una descripción general de qué es el software XRP Ledger disponible y como funciona en conjunto.
labels:
- Servidor central
---
+
# Ecosistema software
El XRP Ledger alberga un ecosistema profundo de varias capas de proyectos de software que impulsan y permiten el Internet del Valor. Es imposible listar cada proyecto, herramienta, y negocio que interactua con el XRP Ledger, asi que esta página solo lista algunas categorías y destaca algunos proyectos centrales que están documentados en este sitio web.
@@ -13,7 +14,7 @@ El XRP Ledger alberga un ecosistema profundo de varias capas de proyectos de sof
## Niveles de stack
-- [_Servidores Principales](#servidores-principales) forman la base del XRP Ledger, una red peer-to-peer que transmite y procesa transacciones en todo momento.
+- [\_Servidores Principales](#servidores-principales) forman la base del XRP Ledger, una red peer-to-peer que transmite y procesa transacciones en todo momento.
- [_Librerías de cliente_](#librerías-cliente) existen en software de alto nivel, donde se importan directamente al código del programa, y contiene métodos para acceder al XRP Ledger.
@@ -21,21 +22,19 @@ El XRP Ledger alberga un ecosistema profundo de varias capas de proyectos de sof
- [_Apps y servicios_](#apps-y-servicios) proporcionan interación con el XRP Ledger a nivel usuario, o proporcionan una base para aplicaciones y servicios de aun más alto nivel.
-
### Servidores principales
-La red peer-to-peer en el corazón del XRP Ledger requiere de un servidor altamente confiable y eficiente para hacer cumplir las reglas de consenso y el procesamiento de las transacciones. La Fundación XRP Ledger publica una implementación de referencia de este software de sevidor, llamada [**`rippled`**](../concepts/networks-and-servers/index.md) (pronunciado en inglés como "ripple-dee"). El servidor está disponible bajo [una licencia permisiva de código abierto](https://github.com/XRPLF/rippled/blob/develop/LICENSE.md), por lo que cualquiera puede inspeccionar y modificar su propia instancia del servidor, y volver a publicar con pocas restricciones.
+La red peer-to-peer en el corazón del XRP Ledger requiere de un servidor altamente confiable y eficiente para hacer cumplir las reglas de consenso y el procesamiento de las transacciones. La Fundación XRP Ledger publica una implementación de referencia de este software de sevidor, llamada [**`rippled`**](../concepts/networks-and-servers/index.md) (pronunciado en inglés como "ripple-dee"). El servidor está disponible bajo [una licencia permisiva de código abierto](https://github.com/XRPLF/rippled/blob/develop/LICENSE.md), por lo que cualquiera puede inspeccionar y modificar su propia instancia del servidor, y volver a publicar con pocas restricciones.

Cada servidor central sincroniza con la misma red (a no ser que esté configurado para seguir una [red de test](../concepts/networks-and-servers/parallel-networks.md)) y tiene acceso a todas las comunicaciones a través de la red. Cada servidor de la red guarda una copia completa de lod datos de estado para todo el XRP Ledger, junto con transacciones recientes y un registro de los cambios que esas transacciones han realizado, y cada servidor procesa cada transacción independientemente mientras verifican que el resultado coincide con el resto de la red. Los servidores pueden ser configurados para mantener más [histórico del ledger](../concepts/networks-and-servers/ledger-history.md) y para participar en el proceso de consenso como un [validador](../concepts/networks-and-servers/rippled-server-modes.md#validators).
-Los servidores Core exponen [APIs HTTP / WebSocket](../references/http-websocket-apis/index.md) para que los usuarios busquen datos, administren el servidor, y envíen transacciones. Algunos servidores también ofrecen APIs HTTP / WebSocket pero no conectan directamente con la red peer-to-peer y no procesan transacciones ni participan en el consenso. Estos servidores, como servidores `rippled` ejecutan en modo Reporting y servidores Clio, que dependen de un servidor central en modo P2P para procesar las transacciones.
-
+Los servidores Core exponen [APIs HTTP / WebSocket](../references/http-websocket-apis/index.md) para que los usuarios busquen datos, administren el servidor, y envíen transacciones. Algunos servidores también ofrecen APIs HTTP / WebSocket pero no conectan directamente con la red peer-to-peer y no procesan transacciones ni participan en el consenso. Estos servidores, como servidores `rippled` ejecutan en modo Reporting y servidores Clio, que dependen de un servidor central en modo P2P para procesar las transacciones.
### Librerías cliente
-Las librerias simplifican parte del trabajo básico de acceder al XRP Ledger, normalmente a través de las APIs HTTP / WebSocket. Convierten los datos en formas que son más familiares y convenientes para varios lenguajes de programación e incluyen implementaiones de operaciones básicas.
+Las librerias simplifican parte del trabajo básico de acceder al XRP Ledger, normalmente a través de las APIs HTTP / WebSocket. Convierten los datos en formas que son más familiares y convenientes para varios lenguajes de programación e incluyen implementaiones de operaciones básicas.

@@ -45,7 +44,6 @@ Muchos servicios middleware utilizan librerías cliente internamente.
Ver [Librerías Cliente](../references/client-libraries.md) para más información sobre las librerías cliente disponibles actualmente.
-
### Middleware
Los servicios middleware son programas que consumen las APIs del XRP Ledger por un lado y proporcionan sus propias APIs por el otro. Porporcionan una capa de abstracción para facilitar la creación de aplicaciones a mayor nivel proporcionando funcionalidades comunes como servicios.
@@ -54,7 +52,6 @@ Los servicios middleware son programas que consumen las APIs del XRP Ledger por
A diferencia de las librerías cliente, en donde se crean instancias nuevas y se cierran con el programa que las importa, los servicios middleware generalmente permanecen ejecutándose indefinidamente y pueden tener sus propias bases de datos (bases de datos relacionales SQL o de otro tipo) y archivos de configuración. Algunos están disponibles como servicios en la nube con varios precios o limitaciones de uso.
-
### Apps y servicios
En lo alto del stack es donde suceden las cosas realmente interesantes. Las apps y servicios ofrecen una forma para que usuarios y dispositivos se conecten al XRP Ledger. Los servicios como los exchanges privados, los acuñadores de tokens, marketplaces, interfaces al exchanges descentralizado, y carteras brindan interfaces de usuario para comprar, vender y comerciar varios activos incluyendo XRP y tokens de todo tipo. Existen muchas otras posibilidades, incluyendo servicios adicionales en capas superiores.
@@ -63,4 +60,4 @@ En lo alto del stack es donde suceden las cosas realmente interesantes. Las apps
Ver [Casos de uso](../use-cases/index.md) para más ejemplos que pueden ser construidos en o encima de esta capa.
-{% raw-partial file="/docs/_snippets/common-links.md" /%}
\ No newline at end of file
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
diff --git a/@l10n/es-ES/docs/introduction/transactions-and-requests.md b/@l10n/es-ES/docs/introduction/transactions-and-requests.md
index 8329151ae2..b74cd8e3e0 100644
--- a/@l10n/es-ES/docs/introduction/transactions-and-requests.md
+++ b/@l10n/es-ES/docs/introduction/transactions-and-requests.md
@@ -2,7 +2,7 @@
html: txn-and-requests.html
parent: intro-to-xrpl.html
seo:
- description: Todas las interacciones con el ledger son transacciones o solicitudes.
+ description: Todas las interacciones con el ledger son transacciones o solicitudes.
labels:
- Blockchain
---
@@ -17,7 +17,7 @@ Utiliza las transacciones para realizar cambios en el ledger, como transferir XR
- Siempre debes proporcionar el _TransactionType_ y la dirección pública de la _Account_ que realiza la transacción.
-- Dos campos obligatorios son la _Fee_ (comisión) de la transacción y el siguiente número de la _Sequence_ (secuencia) para las transacciones de la cuenta. Estos campos se pueden completar automáticamente.
+- Dos campos obligatorios son la _Fee_ (comisión) de la transacción y el siguiente número de la _Sequence_ (secuencia) para las transacciones de la cuenta. Estos campos se pueden completar automáticamente.
- Las transacciones también pueden tener campos obligatorios específicos del tipo de transacción. Por ejemplo, una transacción _Payment_ requiere un valor (cantidad) _Amount_ (en _drops_, o millonésimas de un XRP) y una dirección pública _Destination_ (destino) donde los fondos son acreditados.
@@ -34,7 +34,7 @@ Aquí hay un ejemplo de transacción en formato JSON. Esta transacción transfie
Hay campos opcionales disponibles para todas las transacciones, con campos adicionales disponibles para transacciones específicas. Puedes incluir tantos campos opcionales como necsites, pero no es necesario incluir todos los campos en cada transacción.
-Puedes enviar la transacción al ledger como un comando de JavaScript, Python, línea de comandos, o cualquier servicio compatible. Los servidores rippled proponen las transacciones al XRPL.
+Puedes enviar la transacción al ledger como un comando de JavaScript, Python, línea de comandos, o cualquier servicio compatible. Los servidores rippled proponen las transacciones al XRPL.

@@ -110,6 +110,7 @@ La solicitud devuelve una gran cantidad de información. Aquí hay un ejemplo de
}
}
```
+
Para obtener información sobre los campos de un registro de información de una cuenta, ver [Cuentas](../concepts/accounts/index.md).
Siguiente: [Ecosistema de software](software-ecosystem.md)
diff --git a/@l10n/es-ES/docs/introduction/what-is-the-xrp-ledger.md b/@l10n/es-ES/docs/introduction/what-is-the-xrp-ledger.md
index b676a930fa..ae46a03edf 100644
--- a/@l10n/es-ES/docs/introduction/what-is-the-xrp-ledger.md
+++ b/@l10n/es-ES/docs/introduction/what-is-the-xrp-ledger.md
@@ -2,15 +2,15 @@
html: what-is-the-xrp-ledger.html
parent: introduction.html
seo:
- description: Aprende sobre la blockchain XRP Ledger (XRPL).
+ description: Aprende sobre la blockchain XRP Ledger (XRPL).
labels:
- Blockchain
---
+
# ¿Qué es el XRP Ledger?
El XRP Ledger es una blockchain descentralizada que usa su propia moneda digital para procesar y registrar transacciones financieras.
-
## ¿Qué es una blockchain?
Una blockchain es una lista de registros en continuo creciemiento. La blockchain comienza con un bloque de datos.
@@ -45,7 +45,7 @@ Por diseño, las blockchains son resistentes a la modificación de datos. Cada n

-Esto crea un libro contable (ledger) abierto y distribuido que registra las transacciones entre partes de manera eficiente, verificable y permanente.
+Esto crea un libro contable (ledger) abierto y distribuido que registra las transacciones entre partes de manera eficiente, verificable y permanente.
Una vez registrados, los datos de cualquier bloque no se pueden modificar retroactivamente, a no ser que la mayoría de validadores se pongan de acuerdo en el cambio. Si es así, todo los bloques posteriores se modifican de la misma manera (un hecho muy raro y extremo).
diff --git a/@l10n/es-ES/docs/introduction/what-is-xrp.md b/@l10n/es-ES/docs/introduction/what-is-xrp.md
index 4629e99b9b..f9d58a02dd 100644
--- a/@l10n/es-ES/docs/introduction/what-is-xrp.md
+++ b/@l10n/es-ES/docs/introduction/what-is-xrp.md
@@ -2,11 +2,12 @@
html: what-is-xrp.html
parent: introduction.html
seo:
- title: ¿Qué es XRP y por qué es valioso?
- description: XRP, la criptomoneda respaldada por el XRP Ledger (XRPL), permite transacciones más rápidas y económicas. Descubre cómo opera XRP en una blockchain de código abierto.
+ title: ¿Qué es XRP y por qué es valioso?
+ description: XRP, la criptomoneda respaldada por el XRP Ledger (XRPL), permite transacciones más rápidas y económicas. Descubre cómo opera XRP en una blockchain de código abierto.
labels:
- Blockchain
---
+
# ¿Qué es XRP?
XRP es la criptomoneda respaldada por el XRP Ledger.
@@ -45,31 +46,28 @@ Aunque puede parecer mucho más seguro tener algo "real en la mano, muchas perso
El valor de las criptomonedas proviene de la confianza que sus poseedores depositan en la moneda. Debido a la naturaleza distribuida de los registros y la protección criptográfica para asegurar los fondos, las criptomonedas podrían considerarse mucho más robustas, seguras, y convenientes que las monedas fiduciarias tradicionales.
-
## XRP es una criptomoneda
El XRP Ledger fue construido entre 2011 y principios de 2012 por Jed McCaleb, Arthur Britto y David Schwartz. En el momento de su creación, había 100 mil millones de XRP. En septiembre de 2012, Jed y Arthur, junto con Chris Larsen formaron Ripple (la compañía, llamada en ese momento OpenCoin Inc.) y decidieron donar 80 mil millones XRP a Ripple a cambio de que Ripple desarrollase en el XRP Ledger.

-Desde entonces, la compañía ha vendido XRP regularmente, lo ha utilizado para fortalecer los mercados de XRP y mejorar la liquidez de la red, e incentivar el desarrollo del ecosistema. En 2017, la compañía colocó [55 mil millones de XRP en escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) para asegurar que la cantidad que entra al suministro general [crece de manera predecible](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) en el futuro inmediato,. Ripple [sitio de rendimiento del mercado XRP](https://ripple.com/xrp/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) informa cuánto XRP tiene la compañía disponible y cuanto tiene bloqueado en escrow en la actualidad.
+Desde entonces, la compañía ha vendido XRP regularmente, lo ha utilizado para fortalecer los mercados de XRP y mejorar la liquidez de la red, e incentivar el desarrollo del ecosistema. En 2017, la compañía colocó [55 mil millones de XRP en escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) para asegurar que la cantidad que entra al suministro general [crece de manera predecible](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) en el futuro inmediato,. Ripple [sitio de rendimiento del mercado XRP](https://ripple.com/xrp/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) informa cuánto XRP tiene la compañía disponible y cuanto tiene bloqueado en escrow en la actualidad.

-
### El nombre
Originalmente, el XRP Ledger se llamaba "Ripple" por la forma en que la tecnología permitía que los pagos [se propagaran a través de múltiples saltos y monedas](../concepts/tokens/fungible-tokens/rippling.md). Para el activo nativo construido dentro del ledger, los creadores eligieron las siglas "XRP" del término "créditos ripple" o "ripples" y el prefijo X por ser una moneda no nacional según el estandar de la [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html). La compañía se registró como "Ripple Labs". El nombre "XRP" empezó a usarse para referirse al activo en todos los contextos, para evitar confusiones con nombres similares de la tecnología y la compañía, y finalmente la empresa acortó su propio nombre a "Ripple". En mayo de 2018, [la comunidad seleccionó un nuevo símbolo "X"](https://twitter.com/xrpsymbol/status/1006925937571713025) para representar XRP y diferenciarlo del logotipo triskelion con el que se conocía anteriormente tanto a la empresa como al activo digital
-| XRP "X" Logo | Ripple triskelion |
-|:---------------------------------------|:------------------------------------|
+| XRP "X" Logo | Ripple triskelion |
+| :------------------------------- | :--------------------------------------------- |
|  |  |
-
### Marca comercial
"XRP" es una marca registrada de la XRPL Foundation en EE.UU. y otros países como China y Estonia.
La solicitud de marca se registró en la Oficina de Patentes y Marcas de los Estados Unidos (USPTO) en 2013 con OpenCoin Inc y Ripple Labs Inc como cesionarios. En 2022, la asignación de marca fue actualizada y ahora está asignada a MITTETULUNDUSÜHING XRP LEDGER TRUST (“XRPLF”).
-
+
Siguiente: [Carteras Cripto](crypto-wallets.md)
diff --git a/@l10n/es-ES/translations.yaml b/@l10n/es-ES/translations.yaml
index 211dbe89b0..d2bbac93ad 100644
--- a/@l10n/es-ES/translations.yaml
+++ b/@l10n/es-ES/translations.yaml
@@ -78,7 +78,7 @@ Contribute to Consensus: Contribuye al consenso
Apply for funding to build your XRPL project: Aplica para financiar la construcción de tu proyecto XRPL
Awarded in a single grant: Premiado en una financiación
Distributed to grant recipients: Distribuido entre los recibidores de la financiación
-Open-source projects funded : Proyectos de código abierto financiados
+Open-source projects funded: Proyectos de código abierto financiados
Learn More: Leer más
Showcase your XRPL project, application or product: Muestra tu proyecto XRPL, aplicación o producto
XRPL Community Spotlight: Destacado en la comunidad XRPL
@@ -153,7 +153,7 @@ Explore, Test, Verify: Explora, prueba, verifica
Explore Dev Tools: Explora las herramientas de desarrollo
Browse By Recommended Pages: Explora entre las páginas recomendadas
Get Free Test XRP: Consigue XRP de prueba gratis
-Generate Testnet Credentials: Genera credenciales de Testnet
+Generate Testnet Credentials: Genera credenciales de Testnet
See full documentation index: Consulta el índice de la documentación completa
Find the XRPL Community Around the World: Encuentra a la comunidad XRPL alrededor del mundo
Events: Eventos
@@ -281,7 +281,7 @@ Trust for: Confianza para
Security: Seguridad
Release Notes: Notas de la versión
Custody: Custodia
-Infrastructure: Infraestructura
+Infrastructure: Infraestructura
Carbon Markets/Sustainability: Mercados de Carbono/Sostenibilidad
Developer Tooling: Herramientas de desarrollo
Gaming: Gaming
diff --git a/@l10n/ja/CODE-OF-CONDUCT.md b/@l10n/ja/CODE-OF-CONDUCT.md
index 35532f8342..dcf3cd9046 100644
--- a/@l10n/ja/CODE-OF-CONDUCT.md
+++ b/@l10n/ja/CODE-OF-CONDUCT.md
@@ -8,19 +8,19 @@
前向きな環境を作り上げることに貢献する行動の例:
-* 友好的で差別のない言葉の使用
-* 異なる観点や経験の尊重
-* 建設的な批判の素直な受け入れ
-* コミュニティーにとっての最善への注力
-* 他のコミュニティーメンバーへの共感の表示
+- 友好的で差別のない言葉の使用
+- 異なる観点や経験の尊重
+- 建設的な批判の素直な受け入れ
+- コミュニティーにとっての最善への注力
+- 他のコミュニティーメンバーへの共感の表示
前向きな環境を作り上げることに貢献しない行動の例:
-* 性的な意味を含む言葉や画像の使用、望まない性的注目や誘いかけ
-* あおり、侮辱的または軽蔑的なコメント、個人攻撃や政治攻撃
-* 公的または私的な嫌がらせ
-* 住所やメールアドレスなどの個人情報の、明確な許可なしでの公開
-* 職場において不適切であると合理的に考えられる、その他の行為
+- 性的な意味を含む言葉や画像の使用、望まない性的注目や誘いかけ
+- あおり、侮辱的または軽蔑的なコメント、個人攻撃や政治攻撃
+- 公的または私的な嫌がらせ
+- 住所やメールアドレスなどの個人情報の、明確な許可なしでの公開
+- 職場において不適切であると合理的に考えられる、その他の行為
## 責任
@@ -43,4 +43,5 @@
この行動規範は、[コントリビューター行動規範][ホームページ]バージョン1.4(https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)から抜粋したものです。
[ホームページ]: https://www.contributor-covenant.org
+
この行動規範に関するよくある質問と回答については、https://www.contributor-covenant.org/faq をご覧ください。
diff --git a/@l10n/ja/about/faq.md b/@l10n/ja/about/faq.md
index b482cf3149..c2fd0f4898 100644
--- a/@l10n/ja/about/faq.md
+++ b/@l10n/ja/about/faq.md
@@ -1,14 +1,16 @@
---
seo:
- description: XRP Ledger、XRPLエコシステム、コミュニティに関するよくある質問にお答えします。
+ description: XRP Ledger、XRPLエコシステム、コミュニティに関するよくある質問にお答えします。
subtitle: XRPLについての質問にお答えします
top_nav_grouping: 概要
labels:
- ブロックチェーン
---
+
# よくある質問
+
#### XRPはリップルと呼ぶのですか?
いいえ。XRPは**エックスアールピー**と呼びます。日本国内の多くの取引所などはXRPをRippleやリップルなどと表記していることがありますが、それは間違いです。
@@ -19,22 +21,18 @@ labels:
いいえ。XRPLは分散型のパブリックブロックチェーンです。トランザクション処理やコンセンサスに影響を与えるような変更は、ネットワークバリデータの80%以上の承認が必要です。Rippleはネットワークへの貢献者の一員ですが、その権利は他の貢献者たちと同じです。ネットワークには150以上のバリデータが参加しており、うちデフォルトのユニークノードリスト(UNL)に登録されているものは35以上です。Rippleはこれらのうち[1つのノード](https://foundation.xrpl.org/2023/03/23/unl-update-march-2023/)を運営しています。
ユニークノードリスト(UNL)に関しては[ユニークノードリスト(UNL)とは何ですか?](#ユニークノードリストunlとは何ですか)の項目をご覧ください。
-
#### プルーフ・オブ・ワーク(PoW)が最善の検証メカニズムではないのですか?
プルーフ・オブ・ワークは、信頼できる第三者を必要とせずに二重支出の問題を解決する最初のコンセンサンス・メカニズムでした。[XRP Ledgerのコンセンサスメカニズム](../docs/concepts/consensus-protocol/index.md)は、同じ問題をはるかに速く、安く、より良いエネルギー効率で解決します。
-
#### XRPLではXRP以外の通貨も取引できますか?
はい。XRPLは米ドル、ユーロ、石油、金、リワードポイントなど、任意の資産をトークン化できるように構築されており、どんな通貨でもXRPL上で発行することができます。成長中のXRPLコミュニティは様々なフィアットトークンや暗号通貨をサポートしており、これを裏付けています。
-
#### XRPLは決済専用ではないのですか?
いいえ。当初は決済のユースケース向けに開発されましたが、台帳であるXRP Ledgerとそのネイティブ・デジタルアセットであるXRPの両方は、NFTなどのブロックチェーンの革新的ユースケースで更に人気を集めています。自動マーケットメーカー(AMM)、スマートコントラクト機能Hooks、相互運用サイドチェーンの開発などが現在進行中です。
-
## バリデータ(検証者)とユニークノードリスト
#### トランザクション(取引)のバリデータはどのようなサービスを提供するのですか?
@@ -43,27 +41,22 @@ labels:
コンセンサスプロセスの詳細は、[コンセンサス](../docs/concepts/consensus-protocol/index.md)をご覧ください。
-
#### バリデータの実行にはいくらかかりますか?
バリデータを実行するのに手数料やXRPは必要ありません。メールサーバを稼働するための電気代相当です。
-
#### ユニークノードリスト(UNL)とは何ですか?
UNLとは、ある参加者が共謀しないと信じるバリデータのリストです。各サーバ運営者は自分のUNLを選ぶことができますが、通常は信頼できる発行元から提供されたデフォルトを参考にします。(信頼できる発行元からのデフォルトセットはデフォルトUNLまたは _dUNL_ と呼ばれることがあります)。
-
#### どのUNLを選択すればよいですか?
バリデータは誰でも実行できるため、信頼できるバリデータを選ぶ責任はネットワーク参加者にあります。現在、RippleとXRP Ledger財団が、過去の実績、証明された身元、責任あるITポリシーに基づき、高品質なバリデータの推奨デフォルトリストを公表していることが知られています。しかし、すべてのネットワーク参加者は、自身が信頼できるバリデータを選択することができ、上記の2つの発行者のいずれかに従う必要はありません。
-
#### RippleがそのUNLの採用を推奨しているなら、それは中央集権的なシステムを形成することにならないのですか?
いいえ。XRP Ledgerネットワークはオプトイン方式です。各参加者は直接的または間接的に自身のUNLを選択することができます。万が一、Rippleが活動を停止したり、Rippleが悪意を持って行動したりした場合、参加者は自身のUNLを変更してXRP Ledgerを引き続き使用することができます。
-
#### バリデータにとってインセンティブとなるものは何ですか?
バリデータを運営する主なインセンティブは、ネットワークの安定的な運用と健全な進化を維持・保護することです。XRP Ledgerの進化を決定するのはバリデータであり、XRP Ledgerを利用する、あるいはXRP Ledgerに依存するビジネスには、ネットワークの信頼性と安定性を確保するインセンティブが内在しています。バリデータはまた、このように貢献することでコミュニティからの評価と信頼を得ることができます。
@@ -72,12 +65,10 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ
インセンティブがどのようにバリデータの行動を歪めるかの例については、[miner extractable value (MEV)](https://arxiv.org/abs/1904.05234)をご覧ください。
-
#### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?
いいえ。トランザクション選択のためにカスタマイズされたバリデータポリシーを金融機関が設定することはできません。バリデータは既存のプロトコルに従う、従わないのいずれかを選択します。ソフトウェアは、プロトコルルールに従わない場合は機能しません。そのため、金融機関が社内の専門知識なしにカスタム実装を求めることは推奨されません。
-
#### ネットワーク内の20%を超えるノードが他の多数ノードと一致しない場合はどうなりますか? レジャー(台帳)の最終バージョンはどのように選択されますか?
通常、あるトランザクションの有効性について係争があった場合、多数派が合意に達するまでそのトランザクションは保留されます。しかしネットワークの20%超が多数派と同じプロトコルルールに従わなかった場合、ネットワークは一時的に停止します。参加者が互いに合意を得たいUNLに基づいてUNLを再設定すれば再開できます。この一時的な処理の遅延は二重支出よりも望ましいでしょう。
@@ -88,7 +79,6 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ
XRP Ledgerのコンセンサスメカニズムが不利な状況でどのように動作するかについては、[攻撃と失敗モードに対するコンセンサスの保護](../docs/concepts/consensus-protocol/consensus-protections.md)をご覧ください。
-
#### XRP Ledgerでは正式なバリデータのオンボーディングプロセスを使用していますか?
いいえ。XRP Ledgerは、中央権限のないシステムであるため、正式なバリデータのオンボーディングプロセスのようなものは存在しません。
@@ -97,7 +87,6 @@ XRP Ledgerのコンセンサスメカニズムが不利な状況でどのよう
推奨事項やベストプラクティスについては、[バリデータとしての`rippled`の実行](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。
-
#### デフォルトUNL(dUNL)がネットワークに最も影響力を持つなら、XRPLは中央集権的ではないでしょうか?
バリデータはdUNLや広く使われているUNLを使わないこともできます。誰でもいつでも自由にUNLを作ることができます。
@@ -106,20 +95,16 @@ XRP Ledgerのコンセンサスメカニズムが不利な状況でどのよう
しかし、もしあなたのUNLが他の人が使っているUNLと十分に重複していなければ、あなたのサーバが他のネットワークからフォークしてしまう危険性があります。あなたのUNLが他の人が使っているUNLと90%以上重なっていれば、フォークから完全に保護されます。重複が少ない場合、同じチェーンをフォローできるかもしれませんが、重複が少ないほど、ネットワークの接続性が悪いほど、UNLに信頼できないバリデータや悪意のあるバリデータがあるほど、フォークする可能性が高くなります。
-
## XRPの役割
-
#### XRPはどのような目的で利用されますか?
XRPはXRP Ledgerのネイティブ資産として、これまでのどのデジタルアセットよりも速く、環境に優しく、安価な次世代の決済を実現するために作られました。XRPはまた、スパムから台帳を保護し、XRP Ledgerの分散型取引所で[通貨のブリッジ](../docs/concepts/tokens/decentralized-exchange/autobridging.md)を行うことがユーザにとって有益である場合に、その役割を果たします。時間とともに、XRP Ledgerコミュニティは、XRPの新しい[ユースケース](/about/uses)やXRP Ledgerそのものを発展させてきました。
-
#### XRP Ledgerにおいて大量のトランザクションに対してはどのように対応しますか?
XRP Ledgerは、スパム対策として、需要に基づいて[トランザクションコスト](../docs/concepts/transactions/transaction-cost.md)を動的に設定するように設計されています。潜在的なXRPの操作による影響は、時価総額とトランザクション量の増加に伴うネットワークサイズの拡大によって最小限に抑えられます。
-
#### マネーロンダリングや疑わしい経済活動に対して、どのような標準操作手順が実施されていますか?
XRP Ledgerネットワークはオープンネットワークであり、すべての取引はオープンに公開されています。
@@ -128,10 +113,8 @@ Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、
[XRP Forensics / xrplorer](https://xrplorer.com/)は、XRP Ledgerのマネーロンダリング、詐欺、詐欺、不正使用を追跡し、最小限に抑えるための勧告リストを維持しています。取引所やその他のサービス・プロバイダは、金融犯罪を防止し対応するためにこのサービスを利用することができます。
-
## セキュリティ上の懸念
-
#### サードパーティにより提供されたコードは審査プロセスはどのようになっていますか?
コードへの貢献のプロセスは、開発者が[`rippled`リポジトリ](https://github.com/xrplf/rippled/)のようなソースコードリポジトリに[プルリクエスト](https://docs.github.com/ja/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)を行うことから始まります。
@@ -140,7 +123,6 @@ Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、
プルリクエストが自動テストに合格し、レビュアーの承認を受けると、信頼できる[リポジトリのメンテナ](https://opensource.guide/best-practices/)が次のベータ版に含めるための手続きを行います。
-
#### RippleはXRP LedgerまたはXRP Ledgerネットワークを所有または管理していますか?
いいえ、RippleはXRP LedgerまたはXRP Ledgerネットワークを所有も管理もしていません。
@@ -149,7 +131,6 @@ Rippleは、コアとなるXRP Ledgerサーバ([`rippled`](https://github.com/
いくつかの団体が推奨バリデータリスト(UNL)を公開しています。2023年7月現在、RippleはデフォルトのUNLにある35のバリデータのうち1つのみを実行しています。
-
#### XRP Ledgerは検証用のコードベースとユーザソフトウェア用のコードベースを区別していますか?
XRP Ledgerの[クライアントライブラリ](../docs/references/client-libraries.md)は、ソフトウェア開発者向けのものです。これらのライブラリは、ネットワークを支え、トランザクションを検証する[XRP Ledgerのコアサーバ](../docs/concepts/networks-and-servers/index.md)とは異なるコードベースとリポジトリを持っています。
diff --git a/@l10n/ja/community/report-a-scam.md b/@l10n/ja/community/report-a-scam.md
index 27428c4271..c06231d35a 100644
--- a/@l10n/ja/community/report-a-scam.md
+++ b/@l10n/ja/community/report-a-scam.md
@@ -2,27 +2,28 @@
html: report-a-scam.html
parent: contribute.html
---
+
# 詐欺の報告
発展する業界において、信頼とセキュリティは非常に重要ですが、詐欺はクリプトとブロックチェーンの進歩を妨げ続けています。Xrplorer forensicsチームのようなXRP Ledgerコミュニティ全体の個人やチームは、詐欺を報告するための無料ツールを提供することで、これらの詐欺行為を抑制する手助けをしています。
## 報告する
+
詐欺に遭ったと思ったら、詐欺の手口や詐欺業者について、できるだけ早く、できるだけ多くの情報を集めるようにしてください。どのように行動すべきかは以下の方法を確認してください。
{% admonition type="warning" name="注意" %}誰もXRP Ledgerのアカウントをフリーズしたり、トランザクションを元に戻したりすることはできません。これはXRP Ledgerブロックチェーンの分散型設計によるものです。{% /admonition %}
1. [Xrplorerの調査チーム](https://xrplorer.com/forensics/submit)に詐欺業者のウォレットアドレスを提出してください。
- これにより、不正行為に使用されたアカウントにフラグを立て、他のユーザ、ウォレット、および取引所に対する追加の監視、自動追跡、および警告に含めることができます。
+ これにより、不正行為に使用されたアカウントにフラグを立て、他のユーザ、ウォレット、および取引所に対する追加の監視、自動追跡、および警告に含めることができます。
2. 最寄りの警察署に通報してください。詐欺業者が捕まれば、お金を取り戻せる場合があります。
3. 詐欺業者が取引所にXRPを送金した場合は、必ず取引所のサポートチームに連絡してください。取引所は詐欺業者の口座をフリーズすることができます。以下は、いくつかの有名な取引所のサポートリンクです。
-
- - [Binance](https://www.binance.com/en/support)
- - [Coinbase](https://help.coinbase.com/)
- - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
- - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
+ - [Binance](https://www.binance.com/en/support)
+ - [Coinbase](https://help.coinbase.com/)
+ - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
+ - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
4. 詐欺業者がXRP Ledger上でXRPを他のトークンと交換した場合、そのトークンの発行者に連絡してください。発行者は[詐欺業者のトラストラインをフリーズする](../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md)ことができるかもしれません。
diff --git a/@l10n/ja/docs/_snippets/data_types/address.md b/@l10n/ja/docs/_snippets/data_types/address.md
index 7da6a32df1..ea9ba2c095 100644
--- a/@l10n/ja/docs/_snippets/data_types/address.md
+++ b/@l10n/ja/docs/_snippets/data_types/address.md
@@ -1,10 +1,10 @@
XRP Ledgerのアカウントは、XRP Ledgerの[base58](../../references/protocol/data-types/base58-encodings.md)フォーマットのアドレスで識別されます。このアドレスはアカウントのマスター[公開鍵](https://en.wikipedia.org/wiki/Public-key_cryptography)から生成され、マスター公開鍵は秘密鍵から生成されます。アドレスはJSON文字列で記述され、以下の特徴があります。
-* 長さは25から35文字
-* 文字`r`から始まる
-* 数字"`0`"、大文字"`O`"、大文字"`I`"、小文字"`l`"を除く英数字
-* 大文字と小文字を区別
-* 4バイトのチェックサムが含まれており、ランダムな文字から有効なアドレスが生成される確率はおよそ232分の1
+- 長さは25から35文字
+- 文字`r`から始まる
+- 数字"`0`"、大文字"`O`"、大文字"`I`"、小文字"`l`"を除く英数字
+- 大文字と小文字を区別
+- 4バイトのチェックサムが含まれており、ランダムな文字から有効なアドレスが生成される確率はおよそ232分の1
{% admonition type="info" name="注記" %}
[宛先タグ](../../concepts/transactions/source-and-destination-tags.md)をアドレスに「組み込む」**X**アドレス形式もあります。これらのアドレスは`X`(メインネット用)または`T`([テストネットワーク](../../concepts/networks-and-servers/parallel-networks.md)用)で始まります。取引所とウォレットは、顧客が知る必要のあるすべてのデータを1つの値で表すためにXアドレスを使用できます。詳細については、[Xアドレスフォーマットサイト](https://xrpaddress.info/)と[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)をご覧ください
diff --git a/@l10n/ja/docs/_snippets/data_types/hash.md b/@l10n/ja/docs/_snippets/data_types/hash.md
index c48710e785..4289b49124 100644
--- a/@l10n/ja/docs/_snippets/data_types/hash.md
+++ b/@l10n/ja/docs/_snippets/data_types/hash.md
@@ -2,8 +2,8 @@ XRP Ledger内の多くのオブジェクト、特にトランザクションと
XRP Ledgerのハッシュ値には、以下の特徴があります。
-* 長さは64文字ちょうどです
-* [16進数](https://en.wikipedia.org/wiki/Hexadecimal)の文字セット: 0-9およびA-Fです。
-* 通常は大文字で記述されます。
+- 長さは64文字ちょうどです
+- [16進数](https://en.wikipedia.org/wiki/Hexadecimal)の文字セット: 0-9およびA-Fです。
+- 通常は大文字で記述されます。
{% admonition type="info" name="注記" %}SHA-512ハーフは、公式に定義されている _SHA-512/256_ ハッシュ関数とほぼ同等のセキュリティーを持ちます。しかし、XRP LedgerはSHA-512/256より前から利用されているため、既存のSHA-512関数上に実装することも容易にできます。(この記事の時点で、暗号ライブラリーでのSHA-512のサポートはSHA-512/256よりはるかに一般的です。){% /admonition %}
diff --git a/@l10n/ja/docs/_snippets/data_types/ledger_index.md b/@l10n/ja/docs/_snippets/data_types/ledger_index.md
index e8b593b59c..e07a234812 100644
--- a/@l10n/ja/docs/_snippets/data_types/ledger_index.md
+++ b/@l10n/ja/docs/_snippets/data_types/ledger_index.md
@@ -2,6 +2,6 @@
レジャーインデックスがレジャーの順番を示すのに対し、[ハッシュ][]値はレジャーの正確なコンテンツを示します。2つのレジャーが同じハッシュ値を持つ場合、それらは必ず同じものです。検証済みレジャーでは、ハッシュ値とレジャーインデックスは等しく有効で、1:1の関係です。しかし、進行中のレジャーに対しては、以下の理由によりその限りでありません。
-* ネットワーク全体でのトランザクションの伝搬遅延が原因で、2つの異なる`rippled`サーバで、同じレジャーインデックスを持つ現行レジャーに対するコンテンツが異なる場合があります。
-* 決済済みレジャーバージョンが複数あり、コンセンサスによる検証が競合している場合があります。このようなレジャーバージョンでは、レジャーインデックスは同じですが、コンテンツは異なります(ハッシュも異なります)。これらの決済済みレジャーのうち、検証済みになるのは1つだけです。
-* 現行のオープンレジャーのハッシュは計算されません。これは、現行レジャーのレジャーインデックスは同じままであっても、コンテンツは時間とともに変化し、ハッシュが変わる可能性があるためです。レジャーのハッシュは、レジャーが閉鎖されるときにのみ計算されます。
+- ネットワーク全体でのトランザクションの伝搬遅延が原因で、2つの異なる`rippled`サーバで、同じレジャーインデックスを持つ現行レジャーに対するコンテンツが異なる場合があります。
+- 決済済みレジャーバージョンが複数あり、コンセンサスによる検証が競合している場合があります。このようなレジャーバージョンでは、レジャーインデックスは同じですが、コンテンツは異なります(ハッシュも異なります)。これらの決済済みレジャーのうち、検証済みになるのは1つだけです。
+- 現行のオープンレジャーのハッシュは計算されません。これは、現行レジャーのレジャーインデックスは同じままであっても、コンテンツは時間とともに変化し、ハッシュが変わる可能性があるためです。レジャーのハッシュは、レジャーが閉鎖されるときにのみ計算されます。
diff --git a/@l10n/ja/docs/_snippets/data_types/public_key.md b/@l10n/ja/docs/_snippets/data_types/public_key.md
index 2aeff9b554..36c024938d 100644
--- a/@l10n/ja/docs/_snippets/data_types/public_key.md
+++ b/@l10n/ja/docs/_snippets/data_types/public_key.md
@@ -1,8 +1,8 @@
XRP Ledgerは、以下のようなさまざまな状況で暗号署名を検証するために、公開鍵を使用します。
-* トランザクションを承認するため。トランザクションに公開鍵が添付されます。公開鍵は、送信元のXRP Ledgerのアドレスか送信者のレギュラーキーアドレスに数学的に関連付けられている必要があります。
-* `rippled`サーバ間のピアツーピア通信の安全を確保するため。これには、データベースが空の状態でサーバが起動する場合に、サーバがランダムに生成する「ノード公開鍵」が使用されます。
-* コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバの運用者が[設定ファイルに定義](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)した「バリデータ公開鍵」が使用されます。
+- トランザクションを承認するため。トランザクションに公開鍵が添付されます。公開鍵は、送信元のXRP Ledgerのアドレスか送信者のレギュラーキーアドレスに数学的に関連付けられている必要があります。
+- `rippled`サーバ間のピアツーピア通信の安全を確保するため。これには、データベースが空の状態でサーバが起動する場合に、サーバがランダムに生成する「ノード公開鍵」が使用されます。
+- コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバの運用者が[設定ファイルに定義](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)した「バリデータ公開鍵」が使用されます。
バリデータ公開鍵とノード公開鍵は、まったく同じフォーマットを使用します。
diff --git a/@l10n/ja/docs/_snippets/etl-source-object.md b/@l10n/ja/docs/_snippets/etl-source-object.md
index 4ed07362aa..5439a963dc 100644
--- a/@l10n/ja/docs/_snippets/etl-source-object.md
+++ b/@l10n/ja/docs/_snippets/etl-source-object.md
@@ -1,13 +1,14 @@
### ETLソースオブジェクト
+
レポートモードサーバでは、`etl_sources`フィールドの各メンバは以下のフィールドを持つオブジェクトです。
-| フィールド | 型 | 説明 |
-|-----------------------------|-------|-------------|
+| フィールド | 型 | 説明 |
+| --------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `connected` | 真偽値 | `true`の場合、レポートモードサーバがこのP2Pモードサーバに接続していることを示します。`false`の場合、サーバに接続していないことを示します。これは設定ミスやネットワーク障害によるものか、P2Pモードサーバが停止している可能性があります。 |
-| `grpc_port` | 文字列 | このレポート モードサーバが接続し、gRPCを介してレジャーデータを取得するように設定されている P2P モード サーバのポート番号。 |
-| `ip` | 文字列 | P2PモードサーバのIPアドレス(IPv4またはIPv6)。 |
-| `last_message_arrival_time` | 文字列 | レポートモードサーバがこのP2Pサーバからメッセージを受信した最新の時刻を示すISO 8601タイムスタンプ。 |
-| `validated_ledgers_range` | 文字列 | `complete_ledgers`と同じ形式で、このP2Pモードサーバが利用可能であると報告する、有効なレジャーのバージョンの範囲。 |
-| `websocket_port` | 文字列 | このレポートモードサーバが、レポートモードから直接提供できないWebSocketリクエストを転送するように設定されているP2Pサーバのポート番号。 |
+| `grpc_port` | 文字列 | このレポート モードサーバが接続し、gRPCを介してレジャーデータを取得するように設定されている P2P モード サーバのポート番号。 |
+| `ip` | 文字列 | P2PモードサーバのIPアドレス(IPv4またはIPv6)。 |
+| `last_message_arrival_time` | 文字列 | レポートモードサーバがこのP2Pサーバからメッセージを受信した最新の時刻を示すISO 8601タイムスタンプ。 |
+| `validated_ledgers_range` | 文字列 | `complete_ledgers`と同じ形式で、このP2Pモードサーバが利用可能であると報告する、有効なレジャーのバージョンの範囲。 |
+| `websocket_port` | 文字列 | このレポートモードサーバが、レポートモードから直接提供できないWebSocketリクエストを転送するように設定されているP2Pサーバのポート番号。 |
diff --git a/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md b/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md
index 0a8cf2a7cb..31e76b929d 100644
--- a/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md
+++ b/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md
@@ -1,4 +1,4 @@
-
@@ -6,11 +6,12 @@
{% interactive-block label=default($label, "Connect") steps=$frontmatter.steps %}
+
# Setup
+
- Machine 1 - An airgapped computer (during setup, it must be connected to the internet to download the files)
- Machine 2 - A normal computer connected to the internet
- Phone - A normal phone with a working camera to scan a QR
## Machine 1 Setup
+
Since this machine will be airgapped, it is best to use Linux as the Operating System.
1. Clone all the files under the [`airgapped-wallet`](https://github.com/XRPLF/xrpl-dev-portal/tree/master/_code-samples/airgapped-wallet/js) directory
@@ -65,24 +71,26 @@ Since this machine will be airgapped, it is best to use Linux as the Operating S
4. Run `node airgapped-wallet.js`
-5. Scan the QR code and fund the account using the [testnet faucet](https://test.bithomp.com/faucet/)
+5. Scan the QR code and fund the account using the [testnet faucet](https://test.bithomp.com/faucet/)
6. Re-run the script and input '1' to generate a new transaction by following the instructions.
7. Use your phone to scan the QR code, then to send the signed transaction to Machine 2 for submission
## Phone Setup
+
The phone requires a working camera that is able to scan a QR code and an internet connection for it to be able to transmit the signed transaction blob to Machine 2.
Once you have signed a transaction in the airgapped machine, a QR code will be generated which will contain the signed transaction blob. Example:
-Scan the QR code using the phone, copy it to the clipboard, and transmit it to Machine 2, which will then be sending it to a rippled node.
+Scan the QR code using the phone, copy it to the clipboard, and transmit it to Machine 2, which will then be sending it to a rippled node.
You can send a message to yourself using Discord, WhatsApp or even e-mail, then open up the message using Machine 2 to receive the signed transaction blob.
## Machine 2 Setup
+
This machine will be used to transmit a signed transaction blob from Machine 1, it would require internet access.
1. Clone all the files under the [`airgapped-wallet`](https://github.com/XRPLF/xrpl-dev-portal/tree/master/_code-samples/airgapped-wallet/js) directory
diff --git a/_code-samples/airgapped-wallet/js/airgapped-wallet.js b/_code-samples/airgapped-wallet/js/airgapped-wallet.js
index 22f8b623c5..3016662ecf 100644
--- a/_code-samples/airgapped-wallet/js/airgapped-wallet.js
+++ b/_code-samples/airgapped-wallet/js/airgapped-wallet.js
@@ -1,10 +1,10 @@
-const crypto = require("crypto")
+const crypto = require('crypto')
const fs = require('fs')
-const fernet = require("fernet");
-const open = require('open');
+const fernet = require('fernet')
+const open = require('open')
const path = require('path')
const prompt = require('prompt')
-const { generateSeed, deriveAddress, deriveKeypair } = require("ripple-keypairs/dist/")
+const { generateSeed, deriveAddress, deriveKeypair } = require('ripple-keypairs/dist/')
const QRCode = require('qrcode')
const xrpl = require('xrpl')
@@ -24,17 +24,13 @@ const WALLET_DIR = 'Wallet'
* @returns {{address: *, seed: *}}
*/
createWallet = function () {
- const seed = generateSeed()
- const {publicKey, privateKey} = deriveKeypair(seed)
- const address = deriveAddress(publicKey)
+ const seed = generateSeed()
+ const { publicKey, privateKey } = deriveKeypair(seed)
+ const address = deriveAddress(publicKey)
- console.log(
- "XRP Wallet Credentials " +
- "Wallet Address: " + address +
- "Seed: " + seed
- )
+ console.log('XRP Wallet Credentials ' + 'Wallet Address: ' + address + 'Seed: ' + seed)
- return {address, seed}
+ return { address, seed }
}
/**
@@ -48,176 +44,178 @@ createWallet = function () {
* @returns {Promise}
*/
signTransaction = async function (xrpAmount, destination, ledgerSequence, walletSequence, password) {
+ const salt = fs.readFileSync(path.join(__dirname, WALLET_DIR, 'salt.txt')).toString()
- const salt = fs.readFileSync(path.join(__dirname, WALLET_DIR , 'salt.txt')).toString()
+ const encodedSeed = fs.readFileSync(path.join(__dirname, WALLET_DIR, 'seed.txt')).toString()
- const encodedSeed = fs.readFileSync(path.join(__dirname, WALLET_DIR , 'seed.txt')).toString()
+ // Hashing salted password using Password-Based Key Derivation Function 2
+ const derivedKey = crypto.pbkdf2Sync(password, salt, 1000, 32, 'sha256')
+
+ // Generate a Fernet secret we can use for symmetric encryption
+ const secret = new fernet.Secret(derivedKey.toString('base64'))
+
+ // Generate decryption token
+ const token = new fernet.Token({
+ secret: secret,
+ token: encodedSeed,
+ ttl: 0,
+ })
+ const seed = token.decode()
+
+ const wallet = xrpl.Wallet.fromSeed(seed)
+
+ const paymentTx = {
+ TransactionType: 'Payment',
+ Account: wallet.classicAddress,
+ Amount: xrpl.xrpToDrops(xrpAmount),
+ Destination: destination,
+ }
+
+ // Normally we would fetch certain needed values like Fee,
+ // LastLedgerSequence snd programmatically, like so:
+ //
+ // const preparedTx = await client.autofill(paymentTx)
+ //
+ // But since this is an airgapped wallet without internet
+ // connection, we have to do it manually:
+ //
+ // paymentTx.Sequence is set in setNextValidSequenceNumber() via sugar/autofill
+ // paymentTx.LastLedgerSequence is set in setLatestValidatedLedgerSequence() via sugar/autofill
+ // paymentTx.Fee is set in getFeeXrp() via sugar/getFeeXrp
+
+ paymentTx.Sequence = walletSequence
+ paymentTx.LastLedgerSequence = ledgerSequence + LEDGER_OFFSET
+ paymentTx.Fee = FEE
+
+ const signedTx = wallet.sign(paymentTx)
+
+ fs.writeFileSync(path.join(__dirname, WALLET_DIR, 'tx_blob.txt'), signedTx.tx_blob)
+ QRCode.toFile(path.join(__dirname, WALLET_DIR, 'tx_blob.png'), signedTx.tx_blob)
+
+ open(path.join(__dirname, WALLET_DIR, 'tx_blob.png'))
+}
+
+main = async function () {
+ if (!fs.existsSync(WALLET_DIR)) {
+ // Create Wallet directory in case it does not exist yet
+ fs.mkdirSync(path.join(__dirname, WALLET_DIR))
+ }
+
+ if (!fs.existsSync(path.join(__dirname, WALLET_DIR, 'address.txt'))) {
+ // Generate a new (unfunded) Wallet
+ const { address, seed } = createWallet()
+
+ prompt.start()
+
+ const { password } = await prompt.get([
+ {
+ name: 'password',
+ description: 'Creating a brand new Wallet, please enter a new password \n Enter Password:',
+ type: 'string',
+ required: true,
+ },
+ ])
+
+ prompt.stop()
+
+ const salt = crypto.randomBytes(20).toString('hex')
+
+ fs.writeFileSync(path.join(__dirname, WALLET_DIR, 'salt.txt'), salt)
// Hashing salted password using Password-Based Key Derivation Function 2
const derivedKey = crypto.pbkdf2Sync(password, salt, 1000, 32, 'sha256')
// Generate a Fernet secret we can use for symmetric encryption
- const secret = new fernet.Secret(derivedKey.toString('base64'));
+ const secret = new fernet.Secret(derivedKey.toString('base64'))
- // Generate decryption token
+ // Generate encryption token with secret, time and initialization vector
+ // In a real-world use case we would have current time and a random IV,
+ // but for demo purposes being deterministic is just fine
const token = new fernet.Token({
- secret: secret,
- token: encodedSeed,
- ttl: 0
+ secret: secret,
+ time: Date.parse(1),
+ iv: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15],
})
- const seed = token.decode();
- const wallet = xrpl.Wallet.fromSeed(seed)
+ const privateKey = token.encode(seed)
- const paymentTx = {
- 'TransactionType': 'Payment',
- 'Account': wallet.classicAddress,
- 'Amount': xrpl.xrpToDrops(xrpAmount),
- 'Destination': destination
- }
+ fs.writeFileSync(path.join(__dirname, WALLET_DIR, 'seed.txt'), privateKey)
+ fs.writeFileSync(path.join(__dirname, WALLET_DIR, 'address.txt'), address)
+ QRCode.toFile(path.join(__dirname, WALLET_DIR, 'address.png'), address)
- // Normally we would fetch certain needed values like Fee,
- // LastLedgerSequence snd programmatically, like so:
- //
- // const preparedTx = await client.autofill(paymentTx)
- //
- // But since this is an airgapped wallet without internet
- // connection, we have to do it manually:
- //
- // paymentTx.Sequence is set in setNextValidSequenceNumber() via sugar/autofill
- // paymentTx.LastLedgerSequence is set in setLatestValidatedLedgerSequence() via sugar/autofill
- // paymentTx.Fee is set in getFeeXrp() via sugar/getFeeXrp
+ console.log(
+ '' +
+ 'Finished generating an account.\n' +
+ 'Wallet Address: ' +
+ address +
+ '\n' +
+ 'Please scan the QR code on your phone and use https://test.bithomp.com/faucet/ to fund the account.\n' +
+ "After that, you're able to sign transactions and transmit them to Machine 2 (online machine).",
+ )
- paymentTx.Sequence = walletSequence
- paymentTx.LastLedgerSequence = ledgerSequence + LEDGER_OFFSET
- paymentTx.Fee = FEE
+ return
+ }
- const signedTx = wallet.sign(paymentTx)
+ prompt.start()
- fs.writeFileSync(path.join(__dirname, WALLET_DIR , 'tx_blob.txt'), signedTx.tx_blob)
- QRCode.toFile(path.join(__dirname, WALLET_DIR , 'tx_blob.png'), signedTx.tx_blob)
+ console.log('' + '1. Transact XRP.\n' + '2. Generate an XRP wallet (read only)\n' + '3. Showcase XRP Wallet Address (QR Code)\n' + '4. Exit')
- open(path.join(__dirname, WALLET_DIR , 'tx_blob.png'))
-}
+ const { menu } = await prompt.get([
+ {
+ name: 'menu',
+ description: 'Enter Index:',
+ type: 'integer',
+ required: true,
+ },
+ ])
-main = async function () {
-
- if (!fs.existsSync(WALLET_DIR )) {
- // Create Wallet directory in case it does not exist yet
- fs.mkdirSync(path.join(__dirname, WALLET_DIR ));
- }
-
- if (!fs.existsSync(path.join(__dirname, WALLET_DIR , 'address.txt'))) {
- // Generate a new (unfunded) Wallet
- const {address, seed} = createWallet()
-
- prompt.start();
-
- const {password} = await prompt.get([{
- name: 'password',
- description: 'Creating a brand new Wallet, please enter a new password \n Enter Password:',
- type: 'string',
- required: true
- }])
-
- prompt.stop();
-
- const salt = crypto.randomBytes(20).toString('hex')
-
- fs.writeFileSync(path.join(__dirname, WALLET_DIR , 'salt.txt'), salt);
-
- // Hashing salted password using Password-Based Key Derivation Function 2
- const derivedKey = crypto.pbkdf2Sync(password, salt, 1000, 32, 'sha256')
-
- // Generate a Fernet secret we can use for symmetric encryption
- const secret = new fernet.Secret(derivedKey.toString('base64'));
-
- // Generate encryption token with secret, time and initialization vector
- // In a real-world use case we would have current time and a random IV,
- // but for demo purposes being deterministic is just fine
- const token = new fernet.Token({
- secret: secret,
- time: Date.parse(1),
- iv: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
- })
-
- const privateKey = token.encode(seed)
-
- fs.writeFileSync(path.join(__dirname, WALLET_DIR , 'seed.txt'), privateKey)
- fs.writeFileSync(path.join(__dirname, WALLET_DIR , 'address.txt'), address)
- QRCode.toFile(path.join(__dirname, WALLET_DIR , 'address.png'), address)
-
- console.log(''
- + 'Finished generating an account.\n'
- + 'Wallet Address: ' + address + '\n'
- + 'Please scan the QR code on your phone and use https://test.bithomp.com/faucet/ to fund the account.\n'
- + 'After that, you\'re able to sign transactions and transmit them to Machine 2 (online machine).')
-
- return
- }
-
- prompt.start();
-
- console.log(''
- + '1. Transact XRP.\n'
- + '2. Generate an XRP wallet (read only)\n'
- + '3. Showcase XRP Wallet Address (QR Code)\n'
- + '4. Exit')
-
- const {menu} = await prompt.get([{
- name: 'menu',
- description: 'Enter Index:',
+ if (menu === 1) {
+ const { password, xrpAmount, destinationAddress, accountSequence, ledgerSequence } = await prompt.get([
+ {
+ name: 'password',
+ description: 'Enter Password',
+ type: 'string',
+ required: true,
+ },
+ {
+ name: 'xrpAmount',
+ description: 'Enter XRP To Send',
+ type: 'number',
+ required: true,
+ },
+ {
+ name: 'destinationAddress',
+ description: 'If you just want to try it out, you can use the faucet account rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe. Enter Destination',
+ type: 'string',
+ required: true,
+ },
+ {
+ name: 'accountSequence',
+ description: "Look up the 'Next Sequence' for the account using test.bithomp.com and enter it",
type: 'integer',
- required: true
- }])
+ required: true,
+ },
+ {
+ name: 'ledgerSequence',
+ description: 'Look up the latest ledger sequence on testnet.xrpl.org and enter it below!',
+ type: 'integer',
+ required: true,
+ },
+ ])
- if (menu === 1) {
- const {
- password,
- xrpAmount,
- destinationAddress,
- accountSequence,
- ledgerSequence
- } = await prompt.get([{
- name: 'password',
- description: 'Enter Password',
- type: 'string',
- required: true
- }, {
- name: 'xrpAmount',
- description: 'Enter XRP To Send',
- type: 'number',
- required: true
- }, {
- name: 'destinationAddress',
- description: 'If you just want to try it out, you can use the faucet account rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe. Enter Destination',
- type: 'string',
- required: true
- }, {
- name: 'accountSequence',
- description: 'Look up the \'Next Sequence\' for the account using test.bithomp.com and enter it',
- type: 'integer',
- required: true
- }, {
- name: 'ledgerSequence',
- description: 'Look up the latest ledger sequence on testnet.xrpl.org and enter it below!',
- type: 'integer',
- required: true
- }])
+ await signTransaction(xrpAmount, destinationAddress, ledgerSequence, accountSequence, password)
+ } else if (menu === 2) {
+ const { address, seed } = createWallet()
+ console.log('Generated readonly Wallet (address: ' + address + ' seed: ' + seed + ')')
+ } else if (menu === 3) {
+ const address = fs.readFileSync(path.join(__dirname, WALLET_DIR, 'address.txt')).toString()
+ console.log('Wallet Address: ' + address)
+ open(path.join(__dirname, WALLET_DIR, 'address.png'))
+ } else {
+ return
+ }
- await signTransaction(xrpAmount, destinationAddress, ledgerSequence, accountSequence, password)
- } else if (menu === 2) {
- const {address, seed} = createWallet()
- console.log('Generated readonly Wallet (address: ' + address + ' seed: ' + seed + ')')
- } else if (menu === 3) {
- const address = fs.readFileSync(path.join(__dirname, WALLET_DIR , 'address.txt')).toString()
- console.log('Wallet Address: ' + address)
- open(path.join(__dirname, WALLET_DIR , 'address.png'))
- } else {
- return
- }
-
- prompt.stop();
+ prompt.stop()
}
-main()
\ No newline at end of file
+main()
diff --git a/_code-samples/airgapped-wallet/js/relay-transaction.js b/_code-samples/airgapped-wallet/js/relay-transaction.js
index 4f5cfe3f1c..3fcce8af37 100644
--- a/_code-samples/airgapped-wallet/js/relay-transaction.js
+++ b/_code-samples/airgapped-wallet/js/relay-transaction.js
@@ -2,36 +2,38 @@ const prompt = require('prompt')
const xrpl = require('xrpl')
sendTransaction = async function (tx_blob) {
- const client = new xrpl.Client('wss://s.altnet.rippletest.net:51233')
- await client.connect()
+ const client = new xrpl.Client('wss://s.altnet.rippletest.net:51233')
+ await client.connect()
- console.log("Connected to node")
+ console.log('Connected to node')
- const tx = await client.submitAndWait(tx_blob)
+ const tx = await client.submitAndWait(tx_blob)
- const txHash = tx.result.hash
- const txDestination = tx.result.Destination
- const txXrpAmount = xrpl.dropsToXrp(tx.result.Amount)
- const txAccount = tx.result.Account
+ const txHash = tx.result.hash
+ const txDestination = tx.result.Destination
+ const txXrpAmount = xrpl.dropsToXrp(tx.result.Amount)
+ const txAccount = tx.result.Account
- console.log("XRPL Explorer: https://testnet.xrpl.org/transactions/" + txHash)
- console.log("Transaction Hash: " + txHash)
- console.log("Transaction Destination: " + txDestination)
- console.log("XRP sent: " + txXrpAmount)
- console.log("Wallet used: " + txAccount)
+ console.log('XRPL Explorer: https://testnet.xrpl.org/transactions/' + txHash)
+ console.log('Transaction Hash: ' + txHash)
+ console.log('Transaction Destination: ' + txDestination)
+ console.log('XRP sent: ' + txXrpAmount)
+ console.log('Wallet used: ' + txAccount)
- await client.disconnect()
+ await client.disconnect()
}
main = async function () {
- const {tx_blob} = await prompt.get([{
- name: 'tx_blob',
- description: 'Set tx to \'tx_blob\' received from scanning the QR code generated by the airgapped wallet',
- type: 'string',
- required: true
- }])
+ const { tx_blob } = await prompt.get([
+ {
+ name: 'tx_blob',
+ description: "Set tx to 'tx_blob' received from scanning the QR code generated by the airgapped wallet",
+ type: 'string',
+ required: true,
+ },
+ ])
- await sendTransaction(tx_blob)
+ await sendTransaction(tx_blob)
}
-main()
\ No newline at end of file
+main()
diff --git a/_code-samples/airgapped-wallet/py/README.md b/_code-samples/airgapped-wallet/py/README.md
index 524bb17d54..a4f0acf3fa 100644
--- a/_code-samples/airgapped-wallet/py/README.md
+++ b/_code-samples/airgapped-wallet/py/README.md
@@ -1,9 +1,10 @@
# Airgapped Wallet
+
Airgapped describes a state where a device or a system becomes fully disconnected from other devices and systems. It is the maximum protection for a system against unwanted visitors/viruses, this allows any sensitive data like a private key to be stored without worry of it being compromised as long as reasonable security practices are being practiced.
This airgapped XRP wallet allows users to sign a Payment transaction in a secure environment without the private key being exposed to a machine connected to the internet. The private key and seed is encrypted by password and stored securely.
-*Note*: You should not use this airgapped wallet in production, it should only be used for educational purposes only.
+_Note_: You should not use this airgapped wallet in production, it should only be used for educational purposes only.
This code sample consists of 2 parts:
@@ -13,6 +14,7 @@ This code sample consists of 2 parts:
Preferably, `airgapped-wallet.py` should be on a Linux machine while `relay-transaction.py` could be on any operating system.
# Security Practices
+
Strongly note that an airgapped system's security is not determined by its code alone but the security practices that are being followed by an operator.
There are channels that can be maliciously used by outside parties to infiltrate an airgapped system and steal sensitive information.
@@ -22,13 +24,14 @@ There are other ways malware could interact across airgapped networks, but they
This is why it is also recommended to encrypt sensitive information being stored in an airgapped machine.
The airgapped machine should have a few rules enforced to close any possible channels getting abused to leak information outside of the machine:
+
### Wifi
- Disable any wireless networking hardware on the airgapped machine. For example, if you have a desktop PC with a Wifi card, open the PC and remove the Wifi hardware. If you cannot do that, you could go to the system’s BIOS or UEFI firmware and disable the Wifi hardware.
### BlueTooth
-- BlueTooth can be maliciously used by neighboring devices to steal data from an airgapped machine. It is recommended to remove or disable the BlueTooth hardware.
+- BlueTooth can be maliciously used by neighboring devices to steal data from an airgapped machine. It is recommended to remove or disable the BlueTooth hardware.
### USB
@@ -37,37 +40,44 @@ The airgapped machine should have a few rules enforced to close any possible cha
Do not reconnect the airgapped machine to a network, even when you need to transfer files! An effective airgapped machine should only serve 1 purpose, which is to store data and never open up a gateway for hackers to abuse and steal data.
# Tutorial
+
For testing purposes, you would need to have 2 machines and 1 phone in hand to scan the QR code.
-1. 1st machine would be airgapped, following the security practices written [here](#security-practices). It stores and manages an XRPL Wallet.
+1. 1st machine would be airgapped, following the security practices written [here](#security-practices). It stores and manages an XRPL Wallet.
2. 2nd machine would be a normal computer connected to the internet. It relays a signed transaction blob to a rippled node.
3. The phone would be used to scan a QR code, which contains a signed transaction blob. The phone would transmit it to the 2nd machine.
The diagram below shows you the process of submitting a transaction to the XRPL:
+
# Setup
+
- Machine 1 - An airgapped computer (during setup, it must be connected to the internet to download the files)
- Machine 2 - A normal computer connected to the internet
- Phone - A normal phone with a working camera to scan a QR
## Machine 1 Setup
+
Since this machine will be airgapped, it is best to use Linux as the Operating System.
1. Install Python 3.8:
**Linux Command Line**:
+
```
sudo apt-get update
sudo apt-get install python3.8 python3-pip
```
+
**Website**: https://www.python.org/downloads/source/
2. Clone all the files under the [`airgapped-wallet`](https://github.com/XRPLF/xrpl-dev-portal/tree/master/_code-samples/airgapped-wallet/py) directory
3. Import all the modules required by running:
+
```
pip install -r requirements.txt
```
@@ -76,27 +86,31 @@ pip install -r requirements.txt
5. Run `airgapped-wallet.py`
-6. Scan the QR code and fund the account using the [testnet faucet](https://test.bithomp.com/faucet/)
+6. Scan the QR code and fund the account using the [testnet faucet](https://test.bithomp.com/faucet/)
7. Re-run the script and input '1' to generate a new transaction by following the instructions.
8. Use your phone to scan the QR code, then to send the signed transaction to Machine 2 for submission
## Machine 2 Setup
+
This machine will be used to transmit a signed transaction blob from Machine 1, it would require internet access.
1. Install Python 3.8
**Linux Command Line**:
+
```
sudo apt-get update
sudo apt-get install python3.8 python3-pip
```
+
**Website**: https://www.python.org/downloads/source/
2. Clone all the files under the [`airgapped-wallet`](https://github.com/XRPLF/xrpl-dev-portal/tree/master/_code-samples/airgapped-wallet/py) directory
3. Import all the modules required by running:
+
```
pip install -r requirements.txt
```
@@ -104,6 +118,7 @@ pip install -r requirements.txt
4. Run `relay-transaction.py` with one argument, the signed transaction blob to submit.
## Phone Setup
+
The phone requires a working camera that is able to scan a QR code and an internet connection for it to be able to transmit the signed transaction blob to Machine 2.
Once you have signed a transaction in the airgapped machine, a QR code will be generated which will contain the signed transaction blob. Example:
diff --git a/_code-samples/amm-clob/README.md b/_code-samples/amm-clob/README.md
index 7abd5a44e8..c5dfb20888 100644
--- a/_code-samples/amm-clob/README.md
+++ b/_code-samples/amm-clob/README.md
@@ -1,3 +1,3 @@
# AMM CLOB Demo
-Simulate how offers interact with each other and AMMs on the XRPL DEX.
\ No newline at end of file
+Simulate how offers interact with each other and AMMs on the XRPL DEX.
diff --git a/_code-samples/amm-clob/js/amm-clob.js b/_code-samples/amm-clob/js/amm-clob.js
index e39b249663..4d6ed45808 100644
--- a/_code-samples/amm-clob/js/amm-clob.js
+++ b/_code-samples/amm-clob/js/amm-clob.js
@@ -1,9 +1,9 @@
-if (typeof module !== "undefined") {
- // Use var here because const/let are block-scoped to the if statement.
- var xrpl = require('xrpl')
- }
+if (typeof module !== 'undefined') {
+ // Use var here because const/let are block-scoped to the if statement.
+ var xrpl = require('xrpl')
+}
-const client = new xrpl.Client("wss://s.devnet.rippletest.net:51233");
+const client = new xrpl.Client('wss://s.devnet.rippletest.net:51233')
client.connect()
let aliceWallet = null
@@ -14,290 +14,313 @@ let aliceWalletBalance = null
let bobWalletBalance = null
// Add an event listener to the startButton
-document.addEventListener("DOMContentLoaded", function() {
- startButton.addEventListener("click", start)
- aCreateOfferButton.addEventListener("click", aliceCreateOffer)
- bCreateOfferButton.addEventListener("click", bobCreateOffer)
-});
+document.addEventListener('DOMContentLoaded', function () {
+ startButton.addEventListener('click', start)
+ aCreateOfferButton.addEventListener('click', aliceCreateOffer)
+ bCreateOfferButton.addEventListener('click', bobCreateOffer)
+})
// Function to get Alice and Bob balances
async function getBalances() {
- aliceWalletBalance = await client.getBalances(aliceWallet.address)
- bobWalletBalance = await client.getBalances(bobWallet.address)
+ aliceWalletBalance = await client.getBalances(aliceWallet.address)
+ bobWalletBalance = await client.getBalances(bobWallet.address)
- aliceWalletField.value = `${aliceWalletBalance[0].value} XRP / ${aliceWalletBalance[1].value} USD`
- bobWalletField.value = `${bobWalletBalance[0].value} XRP / ${bobWalletBalance[1].value} USD`
+ aliceWalletField.value = `${aliceWalletBalance[0].value} XRP / ${aliceWalletBalance[1].value} USD`
+ bobWalletField.value = `${bobWalletBalance[0].value} XRP / ${bobWalletBalance[1].value} USD`
}
// Function to update AMM
async function ammInfoUpdate() {
- const ammInfo = await client.request({
- "command": "amm_info",
- "asset": {
- "currency": "XRP"
- },
- "asset2": {
- "currency": "USD",
- "issuer": issuerWallet.address
- },
- "ledger_index": "validated"
- })
+ const ammInfo = await client.request({
+ command: 'amm_info',
+ asset: {
+ currency: 'XRP',
+ },
+ asset2: {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ },
+ ledger_index: 'validated',
+ })
- ammInfoField.value = JSON.stringify(ammInfo.result.amm, null, 2)
+ ammInfoField.value = JSON.stringify(ammInfo.result.amm, null, 2)
}
// Function to update Alice and Bobs offers
async function updateOffers() {
- const aliceOffers = await client.request({
- "command": "account_offers",
- "account": aliceWallet.address
- })
+ const aliceOffers = await client.request({
+ command: 'account_offers',
+ account: aliceWallet.address,
+ })
- if ( aliceOffers.result.offers == "" ) {
- aliceOffersField.value = `No offers.`
- } else {
- aliceOffersField.value = `${JSON.stringify(aliceOffers.result.offers, null, 2)}`
- }
+ if (aliceOffers.result.offers == '') {
+ aliceOffersField.value = `No offers.`
+ } else {
+ aliceOffersField.value = `${JSON.stringify(aliceOffers.result.offers, null, 2)}`
+ }
- const bobOffers = await client.request({
- "command": "account_offers",
- "account": bobWallet.address
- })
-
- if ( bobOffers.result.offers == "" ) {
- bobOffersField.value = `No offers.`
- } else {
- bobOffersField.value = `${JSON.stringify(bobOffers.result.offers, null, 2)}`
- }
+ const bobOffers = await client.request({
+ command: 'account_offers',
+ account: bobWallet.address,
+ })
+
+ if (bobOffers.result.offers == '') {
+ bobOffersField.value = `No offers.`
+ } else {
+ bobOffersField.value = `${JSON.stringify(bobOffers.result.offers, null, 2)}`
+ }
}
// Function to set up test harness
async function start() {
-
- // Fund wallets and wait for each to complete
- startButton.textContent = "Loading wallets...";
-
- const issuerStart = client.fundWallet()
- const ammStart = client.fundWallet()
- const aliceStart = client.fundWallet()
- const bobStart = client.fundWallet()
+ // Fund wallets and wait for each to complete
+ startButton.textContent = 'Loading wallets...'
- const [issuerResult, ammResult, aliceResult, bobResult] = await Promise.all([issuerStart, ammStart, aliceStart, bobStart])
+ const issuerStart = client.fundWallet()
+ const ammStart = client.fundWallet()
+ const aliceStart = client.fundWallet()
+ const bobStart = client.fundWallet()
- issuerWallet = issuerResult.wallet
- const ammWallet = ammResult.wallet
- aliceWallet = aliceResult.wallet
- bobWallet = bobResult.wallet
+ const [issuerResult, ammResult, aliceResult, bobResult] = await Promise.all([issuerStart, ammStart, aliceStart, bobStart])
- // Set up account settings
- startButton.textContent = "Setting up account settings...";
+ issuerWallet = issuerResult.wallet
+ const ammWallet = ammResult.wallet
+ aliceWallet = aliceResult.wallet
+ bobWallet = bobResult.wallet
- const issuerSetRipple = client.submitAndWait({
- "TransactionType": "AccountSet",
- "Account": issuerWallet.address,
- "SetFlag": xrpl.AccountSetAsfFlags.asfDefaultRipple
- }, {autofill: true, wallet: issuerWallet})
+ // Set up account settings
+ startButton.textContent = 'Setting up account settings...'
- const ammSetTrust = client.submitAndWait({
- "TransactionType": "TrustSet",
- "Account": ammWallet.address,
- "LimitAmount": {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": "10000"
- }
- }, {autofill: true, wallet: ammWallet})
+ const issuerSetRipple = client.submitAndWait(
+ {
+ TransactionType: 'AccountSet',
+ Account: issuerWallet.address,
+ SetFlag: xrpl.AccountSetAsfFlags.asfDefaultRipple,
+ },
+ { autofill: true, wallet: issuerWallet },
+ )
- const aliceSetTrust = client.submitAndWait({
- "TransactionType": "TrustSet",
- "Account": aliceWallet.address,
- "LimitAmount": {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": "10000"
- }
- }, {autofill: true, wallet: aliceWallet})
+ const ammSetTrust = client.submitAndWait(
+ {
+ TransactionType: 'TrustSet',
+ Account: ammWallet.address,
+ LimitAmount: {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: '10000',
+ },
+ },
+ { autofill: true, wallet: ammWallet },
+ )
- const bobSetTrust = client.submitAndWait({
- "TransactionType": "TrustSet",
- "Account": bobWallet.address,
- "LimitAmount": {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": "10000"
- }
- }, {autofill: true, wallet: bobWallet})
+ const aliceSetTrust = client.submitAndWait(
+ {
+ TransactionType: 'TrustSet',
+ Account: aliceWallet.address,
+ LimitAmount: {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: '10000',
+ },
+ },
+ { autofill: true, wallet: aliceWallet },
+ )
- await Promise.all([issuerSetRipple, ammSetTrust, aliceSetTrust, bobSetTrust])
+ const bobSetTrust = client.submitAndWait(
+ {
+ TransactionType: 'TrustSet',
+ Account: bobWallet.address,
+ LimitAmount: {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: '10000',
+ },
+ },
+ { autofill: true, wallet: bobWallet },
+ )
- // Send USD token
- startButton.textContent = "Sending USD...";
+ await Promise.all([issuerSetRipple, ammSetTrust, aliceSetTrust, bobSetTrust])
- const issuerAccountInfo = await client.request({
- "command": "account_info",
- "account": issuerWallet.address
- })
+ // Send USD token
+ startButton.textContent = 'Sending USD...'
- let sequence = issuerAccountInfo.result.account_data.Sequence
+ const issuerAccountInfo = await client.request({
+ command: 'account_info',
+ account: issuerWallet.address,
+ })
- const ammUSD = client.submitAndWait({
- "TransactionType": "Payment",
- "Account": issuerWallet.address,
- "Amount": {
- "currency": "USD",
- "value": "1000",
- "issuer": issuerWallet.address
- },
- "Destination": ammWallet.address,
- "Sequence": sequence ++
- }, {autofill: true, wallet: issuerWallet})
+ let sequence = issuerAccountInfo.result.account_data.Sequence
- const aliceUSD = client.submitAndWait({
- "TransactionType": "Payment",
- "Account": issuerWallet.address,
- "Amount": {
- "currency": "USD",
- "value": "1000",
- "issuer": issuerWallet.address
- },
- "Destination": aliceWallet.address,
- "Sequence": sequence ++
- }, {autofill: true, wallet: issuerWallet})
+ const ammUSD = client.submitAndWait(
+ {
+ TransactionType: 'Payment',
+ Account: issuerWallet.address,
+ Amount: {
+ currency: 'USD',
+ value: '1000',
+ issuer: issuerWallet.address,
+ },
+ Destination: ammWallet.address,
+ Sequence: sequence++,
+ },
+ { autofill: true, wallet: issuerWallet },
+ )
- const bobUSD = client.submitAndWait({
- "TransactionType": "Payment",
- "Account": issuerWallet.address,
- "Amount": {
- "currency": "USD",
- "value": "1000",
- "issuer": issuerWallet.address
- },
- "Destination": bobWallet.address,
- "Sequence": sequence ++
- }, {autofill: true, wallet: issuerWallet})
+ const aliceUSD = client.submitAndWait(
+ {
+ TransactionType: 'Payment',
+ Account: issuerWallet.address,
+ Amount: {
+ currency: 'USD',
+ value: '1000',
+ issuer: issuerWallet.address,
+ },
+ Destination: aliceWallet.address,
+ Sequence: sequence++,
+ },
+ { autofill: true, wallet: issuerWallet },
+ )
- await Promise.all([ammUSD, aliceUSD, bobUSD])
+ const bobUSD = client.submitAndWait(
+ {
+ TransactionType: 'Payment',
+ Account: issuerWallet.address,
+ Amount: {
+ currency: 'USD',
+ value: '1000',
+ issuer: issuerWallet.address,
+ },
+ Destination: bobWallet.address,
+ Sequence: sequence++,
+ },
+ { autofill: true, wallet: issuerWallet },
+ )
- // Update Alice and Bob's XRP and USD balances
+ await Promise.all([ammUSD, aliceUSD, bobUSD])
- getBalances()
+ // Update Alice and Bob's XRP and USD balances
- // Set up AMM
- startButton.textContent = "Creating AMM...";
+ getBalances()
- await client.submitAndWait({
- "TransactionType": "AMMCreate",
- "Account": ammWallet.address,
- "Amount": "50000000", // XRP as drops
- "Amount2": {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": "500"
- },
- "TradingFee": 500 // 0.5%
- }, {autofill: true, wallet: ammWallet})
+ // Set up AMM
+ startButton.textContent = 'Creating AMM...'
- // Update AMM
- ammInfoUpdate()
+ await client.submitAndWait(
+ {
+ TransactionType: 'AMMCreate',
+ Account: ammWallet.address,
+ Amount: '50000000', // XRP as drops
+ Amount2: {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: '500',
+ },
+ TradingFee: 500, // 0.5%
+ },
+ { autofill: true, wallet: ammWallet },
+ )
- startButton.textContent = "Ready (Click to Restart)";
+ // Update AMM
+ ammInfoUpdate()
+ startButton.textContent = 'Ready (Click to Restart)'
}
-
// Submit Alice Offers
async function aliceCreateOffer() {
+ aCreateOfferButton.textContent = 'Creating Offer...'
- aCreateOfferButton.textContent = "Creating Offer..."
+ try {
+ let aliceTakerGets = null
+ let aliceTakerPays = null
- try {
- let aliceTakerGets = null
- let aliceTakerPays = null
-
- if ( aliceTakerGetsCurrency.value == 'XRP' ) {
- aliceTakerGets = xrpl.xrpToDrops(aliceTakerGetsAmount.value)
- } else {
- aliceTakerGets = {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": aliceTakerGetsAmount.value
- }
- }
-
- if ( aliceTakerPaysCurrency.value == 'XRP' ) {
- aliceTakerPays = xrpl.xrpToDrops(aliceTakerPaysAmount.value)
- } else {
- aliceTakerPays = {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": aliceTakerPaysAmount.value
- }
- }
-
- await client.submitAndWait({
- "TransactionType": "OfferCreate",
- "Account": aliceWallet.address,
- "TakerGets": aliceTakerGets,
- "TakerPays": aliceTakerPays
- }, {autofill: true, wallet: aliceWallet})
-
- updateOffers()
- getBalances()
- ammInfoUpdate()
-
- } catch (error) {
- aliceOffersField.value = `${error.message}`
+ if (aliceTakerGetsCurrency.value == 'XRP') {
+ aliceTakerGets = xrpl.xrpToDrops(aliceTakerGetsAmount.value)
+ } else {
+ aliceTakerGets = {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: aliceTakerGetsAmount.value,
+ }
}
- aCreateOfferButton.textContent = "Create Another Offer"
+ if (aliceTakerPaysCurrency.value == 'XRP') {
+ aliceTakerPays = xrpl.xrpToDrops(aliceTakerPaysAmount.value)
+ } else {
+ aliceTakerPays = {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: aliceTakerPaysAmount.value,
+ }
+ }
+
+ await client.submitAndWait(
+ {
+ TransactionType: 'OfferCreate',
+ Account: aliceWallet.address,
+ TakerGets: aliceTakerGets,
+ TakerPays: aliceTakerPays,
+ },
+ { autofill: true, wallet: aliceWallet },
+ )
+
+ updateOffers()
+ getBalances()
+ ammInfoUpdate()
+ } catch (error) {
+ aliceOffersField.value = `${error.message}`
+ }
+
+ aCreateOfferButton.textContent = 'Create Another Offer'
}
// Submit Bob Offers
async function bobCreateOffer() {
+ bCreateOfferButton.textContent = 'Creating Offer...'
- bCreateOfferButton.textContent = "Creating Offer..."
+ try {
+ let bobTakerGets = null
+ let bobTakerPays = null
- try {
- let bobTakerGets = null
- let bobTakerPays = null
-
- if ( bobTakerGetsCurrency.value == 'XRP' ) {
- bobTakerGets = xrpl.xrpToDrops(bobTakerGetsAmount.value)
- } else {
- bobTakerGets = {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": bobTakerGetsAmount.value
- }
- }
-
- if ( bobTakerPaysCurrency.value == 'XRP' ) {
- bobTakerPays = xrpl.xrpToDrops(bobTakerPaysAmount.value)
- } else {
- bobTakerPays = {
- "currency": "USD",
- "issuer": issuerWallet.address,
- "value": bobTakerPaysAmount.value
- }
- }
-
- await client.submitAndWait({
- "TransactionType": "OfferCreate",
- "Account": bobWallet.address,
- "TakerGets": bobTakerGets,
- "TakerPays": bobTakerPays
- }, {autofill: true, wallet: bobWallet})
-
- updateOffers()
- getBalances()
- ammInfoUpdate()
-
- } catch (error) {
- bobOffersField.value = `${error.message}`
+ if (bobTakerGetsCurrency.value == 'XRP') {
+ bobTakerGets = xrpl.xrpToDrops(bobTakerGetsAmount.value)
+ } else {
+ bobTakerGets = {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: bobTakerGetsAmount.value,
+ }
}
- bCreateOfferButton.textContent = "Create Another Offer"
-}
\ No newline at end of file
+ if (bobTakerPaysCurrency.value == 'XRP') {
+ bobTakerPays = xrpl.xrpToDrops(bobTakerPaysAmount.value)
+ } else {
+ bobTakerPays = {
+ currency: 'USD',
+ issuer: issuerWallet.address,
+ value: bobTakerPaysAmount.value,
+ }
+ }
+
+ await client.submitAndWait(
+ {
+ TransactionType: 'OfferCreate',
+ Account: bobWallet.address,
+ TakerGets: bobTakerGets,
+ TakerPays: bobTakerPays,
+ },
+ { autofill: true, wallet: bobWallet },
+ )
+
+ updateOffers()
+ getBalances()
+ ammInfoUpdate()
+ } catch (error) {
+ bobOffersField.value = `${error.message}`
+ }
+
+ bCreateOfferButton.textContent = 'Create Another Offer'
+}
diff --git a/_code-samples/amm-clob/js/demo.html b/_code-samples/amm-clob/js/demo.html
index 102b37d039..3860b1bdb7 100644
--- a/_code-samples/amm-clob/js/demo.html
+++ b/_code-samples/amm-clob/js/demo.html
@@ -6,36 +6,40 @@