diff --git a/@i18n/es-ES/community/report-a-scam.md b/@i18n/es-ES/community/report-a-scam.md new file mode 100644 index 0000000000..591741af29 --- /dev/null +++ b/@i18n/es-ES/community/report-a-scam.md @@ -0,0 +1,31 @@ +--- +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. + +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) + +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. + +Para más detalles sobre reportar estafadores, consultar [Ayuda de Xrplorer Forensics](https://xrplorer.com/forensics/help). + +Para pedir ayuda de la comunidad de XRP Ledger, también puedes probar el [foro XRPChat](https://xrpchat.com). diff --git a/@i18n/es-ES/docs/accounts/account-types.md b/@i18n/es-ES/docs/concepts/accounts/account-types.md similarity index 100% rename from @i18n/es-ES/docs/accounts/account-types.md rename to @i18n/es-ES/docs/concepts/accounts/account-types.md diff --git a/@i18n/es-ES/docs/accounts/addresses.md b/@i18n/es-ES/docs/concepts/accounts/addresses.md similarity index 100% rename from @i18n/es-ES/docs/accounts/addresses.md rename to @i18n/es-ES/docs/concepts/accounts/addresses.md diff --git a/@i18n/es-ES/docs/accounts/cryptographic-keys.md b/@i18n/es-ES/docs/concepts/accounts/cryptographic-keys.md similarity index 100% rename from @i18n/es-ES/docs/accounts/cryptographic-keys.md rename to @i18n/es-ES/docs/concepts/accounts/cryptographic-keys.md diff --git a/@i18n/es-ES/docs/accounts/decentralized-identifiers.md b/@i18n/es-ES/docs/concepts/accounts/decentralized-identifiers.md similarity index 100% rename from @i18n/es-ES/docs/accounts/decentralized-identifiers.md rename to @i18n/es-ES/docs/concepts/accounts/decentralized-identifiers.md diff --git a/@i18n/es-ES/docs/accounts/deleting-accounts.md b/@i18n/es-ES/docs/concepts/accounts/deleting-accounts.md similarity index 100% rename from @i18n/es-ES/docs/accounts/deleting-accounts.md rename to @i18n/es-ES/docs/concepts/accounts/deleting-accounts.md diff --git a/@i18n/es-ES/docs/accounts/depositauth.md b/@i18n/es-ES/docs/concepts/accounts/depositauth.md similarity index 100% rename from @i18n/es-ES/docs/accounts/depositauth.md rename to @i18n/es-ES/docs/concepts/accounts/depositauth.md diff --git a/@i18n/es-ES/docs/accounts/index.md b/@i18n/es-ES/docs/concepts/accounts/index.md similarity index 100% rename from @i18n/es-ES/docs/accounts/index.md rename to @i18n/es-ES/docs/concepts/accounts/index.md diff --git a/@i18n/es-ES/docs/accounts/multi-signing.md b/@i18n/es-ES/docs/concepts/accounts/multi-signing.md similarity index 100% rename from @i18n/es-ES/docs/accounts/multi-signing.md rename to @i18n/es-ES/docs/concepts/accounts/multi-signing.md diff --git a/@i18n/es-ES/docs/accounts/reserves.md b/@i18n/es-ES/docs/concepts/accounts/reserves.md similarity index 100% rename from @i18n/es-ES/docs/accounts/reserves.md rename to @i18n/es-ES/docs/concepts/accounts/reserves.md diff --git a/@i18n/es-ES/docs/accounts/tickets.md b/@i18n/es-ES/docs/concepts/accounts/tickets.md similarity index 100% rename from @i18n/es-ES/docs/accounts/tickets.md rename to @i18n/es-ES/docs/concepts/accounts/tickets.md diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md new file mode 100644 index 0000000000..5f347840bb --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-principles-and-rules.md @@ -0,0 +1,131 @@ +--- +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. +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). + +La tencología del XRP Ledger permite liquidaciones casi en tiempo real (de tres a seis segundos) y contiene un exchange descentralizado, donde los pagos automáticamente usan las ordenes de intercambio de divisas más baratas para conectar divisas. + +## Transfondo + +### Mecánicas + +Principalmente, el XRP Ledger es una base de datos compartida que registra información como cuentas, balances, y ofertas para comerciar con activos. Las instrucciones firmadas llamadas "transacciones" generan cambios como la creación de cuentas, generación de pagos, y comerciar activos. + +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. + +Supongamos que Alice, Bob, y Charlie están usando un sistema de pagos, y Alice tiene un balance de 10$. Para que el sistema de pagos sea útil, Alice debe ser capaz de enviar sus 10$ a Bob, o a Charlie. Sin embargo, si Alice intenta enviar 10$ a Bob y también envía 10$ a Charlie al mismo tiempo, ahí es donde el problema del doble gasto aparece. + +Si Alice puede enviar los "mismos" 10$ a ambos Charlie y Bob, el sistema de pagos dejará de ser útil. El sistema de pagos necesita una forma de elegir que transacción debería suceder y cual debería fallar, de una forma que todos los participantes estén de acuerdo en que transacción ha ocurrido. Cualquiera de esas transacciones son igual de válidas por si mismas. Sin embargo, los distintos participantes pueden tener una diferente visión de que transacción llegó antes en el sistema de pagos. + +Convencionalmente, los sistemas de pagos resuelven el problema del doble gasto teniendo una autoridad central que rastrea y aprueba transaciones. Por ejemplo, un banco decide compensar un cheque en función del saldo disponible del emisor, del cual el banco es el único custodio. En tal sistema, todos los participantes siguen las deicisiones de la autoridad central. + +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 + +Gran parte del problema del doble gasto puede ser resuelto por unas reglas bien conocidas como prohibir a una cuenta que gaste fondos que no tiene. De hecho, el problema del doble gasto se puede reducir a poner transacciones en orden. + +Considerando el ejemplo de Alice intentando enviar los mismos 10$ a ambos Bob y Charlie. Si el pago se sabe que es el primero, entonces todo el mundo estará de acuerdo de que ella tiene los fondos para pagar a Bob. Si el pago a Charlie se sabe que es el segundo, entonces cualquiera estará de acuerdo de que ella no tiene esos fondos para Charlie porque el dinero ya ha sido enviado a Bob. + +También podemos ordenar transacciones por reglas deterministas. Porque las transacciones son colecciones de información digital, es trivial par aun ordenador ordenarlas. + +Esto sería suficiente para solventar el problema del doble gasto sin una autoridad central, pero requeriría tener cada transacción que ocurriese (para así poder ordenarlas) antes de poder estar seguros de los resultados de cualquier transacción. Obviamente, no es práctico. + +Si pudiesemos recopilar transacciones en grupos y acordar esas agrupaciones, podríamos ordenar las transacciones de ese grupo. Siempre que cada participante esté de acuerdo en qué transacciones se procesarán como una unidad, pueden usar reglas deterministas para resolver el problema del doble gasto sin necesidad de una autoridad central. Cada uno de los participantes clasifica las transacciones y las aplica de forma determinista siguiendo las reglas conocidas. El XRP Ledger resuelve el problema del doble gasto exáctamente de esta manera. + +El XRP Ledger permite que múltiples transacciones conflictivas estén en el grupo acordado. El grupo de transacciones es ejecutado de acuerdo a unas reglas deterministas, por lo que la transacción que ocurra primero según las reglas de clasificación tendrá éxito y la transacción conflictiva que ocurra en segundo lugar fallará. + +### Reglas de consenso + +La función principal del consenso es que los participantes en el proceso acuerden qué transacciones se procesarán como grupo para resolver el problema del doble gasto. Hay cuatro razones por las que este acuerdo es más fácil de conseguir de lo que cabría esperar: + +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. +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. + +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. + +Para prevenir que el consenso se atasque cerca del 50% y para reducir el superposición requerida para una convergencia confiable, el umbral requerido para incluir una transacción incrementa con el tiempo. Inicialmente, los participantes continuan acordando incluir una transacción si el 50% o más del resto de participantes está de acuerdo. Si los participantes discrepan, ellos incrementan este umbral, primero a 60% y luego más mayor, hasta que todas las transacciones discutidas son eliminadas del conjunto actual. Cualquier transacción eliminada de este modo se apartan a la siguiente versión de un ledger. + +Cuando un participante ve a una sobremayoría que está de acuerdo en el conjunto de transacciones que van a ser procesadas, declara que un consenso ha sido alcanzado. + +### 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. + +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.. + +En otras palabras, para que el proceso de consenso pueda finalizar, algún participante debe declarar que el consenso se ha alcanzado en un conjunto de transacciones incluso aunque cualquier otro participante teóricamente puede todavía ser capaz de cambiar el conjunto acordado de transacciones. + +Imagina un grupod e personas en una habitación intentando acordar qué puerta deberían utilizar para salir. No importa cuanto discutan los participantes, en algún momento, _alguien_ tiene que ser el primero en pasar por la puerta, incluso aunque las personas después de esta persona puede todavía cambiar su opinión y salir por otra puerta. + +La probabilidad de este tipo de fallo puede ser muy baja, pero no se puede reducir a cero. El balance de ingeniería es tal que llevar esta probabilidad por debajo por debajo de uno entre mil hacer el consenso significamente más lento, y menos tolerable a fallos de endpoint o de red. + +### Cómo maneja los fallos de consenso el XRP Ledger + +Después de que una ronda de consenso se complete, cada participante aplica el conjunto de transacciones que cree que se ha agregado. Esto resulta en la contrucción de lo que ellos creen que será el próximo estado del ledger que debería ser. + +Los participantes que también son validadores publican entonces una huella criptográfica para el siguiente ledger. Llamamos a esa huella un "voto de validación". Si la ronda de consenso ocurre, la gran mayoría de validadores honestos deberían publicar la misma huella. + +Después, los participantes recolectan estos votos de validación. Con los votos de validación, pueden determinar si la ronda de consenso anterior resultó en una supermayoría de participantes acordando el conjunto de datos o no. + +Luego, los participantes se encontrarán a si mismos en uno de estos tres casos, en orden de probabilidad: + +1. Contruyeron el mismo ledger que la mayoría ha acordado. En este caso, pueden considerar que ese ledger está validado y se puede confiar en su contenido. +2. Construyeron un ledger diferente al acordado por la supermayoría. En este caso, deben construir y aceptar el ledger de la supermayoría. Esto suele indicar que han declarado conenso antes y otros participantes cambiaron después de eso. Deben "saltar" al ledger de la supermayoría para continuar la operación. +3. Si la supermayoría no está clara de las validaciones recibidas. En este caso, la ronda de consenso previa se ha malgastado y una nueva ronda debe ocurrir antes de que ningún ledger sea validado. + +Por supuesto, el caso 1 es el más común. El caso 2 no daña a la red en absoluto. Un pequeño porcentaje de participantes podría caer en el caso 2 cada ronda, y la red podría funcionar sin problemas. Incluso esos participantes pueden reconocer que no han construido el mismo ledger que la supermayoría, por lo que saben que no reportarán sus resultados hasta el final cuando estén de acuerdo con la supermayoría. + +El caso 3 resulta en la red perdiendo unos segundos en los que podría haber avanzado, pero esto es extremadamente raro. En este caso, la siguiente ronda de consenso es mucho menos probable que falle porque los desacuerdos están resueltos en el proceso de consenso y solo los descauerdos restantes pueden provocar un fallo. + +En raras ocasiones, la red como conjunto falla para progresar hacia adelante por unos segundos. A cambio, los tiempos de confirmaciones de transacciones son bajos. + +## Filosofía + +Una forma de confiar es la habilidad del sistema de proveer resultados incluso en situaciones donde algunos componentes han fallado, algunos participante son maliciosos, y así. Mientras esto es importante, hay otra forma de confiar que es mucho más importante en los sistemas de pagos criptográficos - la habilidad de un sistema para producir resultados en los que se puede confiar. Eso ocurre, cuando un sistema nos reporta un resultado es confiable, debemo ser capaces de confiar en ese resultado. + +Los sistemas del mundo real, sin embargo, se enfrentan a condiciones operacionales en que ambos tipos de confiabilidad puede ser comprometida. Esto incluye fallos de hardware, fallos de comunicación, incluso participantes deshonestos. Parte de la filosofía del diseño del XRP Ledger es detectar condiciones donde la confianza de resultados está dañada y hay que reportarlos, en vez de facilitar resultados en los que no se debe confiar. + +El algoritmo de consenso del XRP Ledger provee una alternativa robusta a sistemas de prueba de trabajo (proof of work), sin consumir recursos computacionales innecesariamente. Los fallos bizantinos son posibles, y ocurren, pero la consecuencia son solo retrasos menores. En todos los casos, el algoritmo de consenso de XRP Ledger informa que los resultados son confiables solo cuando de hecho lo son. + +## 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) +- **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) +- **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][] + +{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md new file mode 100644 index 0000000000..0dd08a2afc --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-protections.md @@ -0,0 +1,73 @@ +--- +html: consensus-protections.html +parent: consensus.html +blurb: 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. + +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. + +## Validadodes individuales con mal comportamiento + +Los _validadores_ son servidores que contribuyen activamente al proceso de decidir cada nueva versión del ledger. Los validadores tienen una influencia sobre servidores configurados para confiar en ellos (incluso indiréctamente). El consenso continua incluso si algunos validadores se comportan mal, incluyendo una larga variedad de casos de fallo, tales como: + +- No estar disponibles o sobrecargados. +- Estar parcialmente desconectados de la red, por lo que sus mensajes solo alcanzan a un subgrupo de participantes sin retraso. +- Comportarse intencionadamente para defraudar a otros o parar la red. +- Comportarse maliciosamente como resultado de la presión de factores externos, como amenzadas de un gobierno opresivo. +- Enviar accidentalmente mensajes confusos o malformados debido a un error o una software desactualizado. + +En general, el consenso puede continuar sin problemas mientras solo un pequeño porcentaje (menos del 20%) de los validadores confiables tengan mal comportamiento en un mismo momento. (Para las matemáticas que hay detrás y los porcentajes exactos, ver la última [Investigración del consenso](consensus-research.md).) + +Si más del 20% de los validadores son inalcanzables o no se comportan adecuadamente, la red falla al intentar consenso. Durante este tiempo, nuevas transacciones pueden ser tentativamente procesadas, pero las nuevas versiones del ledger no pueden ser validadas, así que los resultados finales de esas transacciones no son ciertos. En esta situación, se convierte en inmediatamente obvio que el XRP Ledger no se encuentra bien, lo que provocaría una intervención de participantes humanos que pueden decidir entre esperar, o reconfigurar el conjuntos de validadores confiables. + +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: + +- Un [código fuente open-source](https://github.com/XRPLF/rippled/), por lo que cualquier miembro del público puede revisar, compilar, e independientemente probar el software relevante. +- Un proceso de revisión de código exhaustivo y sólido para todos los cambios de los repositorios oficiales del XRP Ledger. +- Las firmas digitales de desarrolladores muy conocidos en todas las publicaciones y paquetes de software. +- 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.) + +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. + +Por defecto, los servidores XRP Ledger están configurados para utilizar sitios de listas de validadores mantenidas por la XRPL Foundation y Ripple. Los sitios proveen una lista de validadores recomendados (también conocidos como la _Lista de Nodos Únicos_ recomendada, o UNL), la cual se actualiza periódicamente. Los servidores configurados de esta forma confian en todos los validadores de la última versión de la lista, lo cual asegura un 100% de superposición con otros que usan la misma lista. La configuración por defecto incluye claves públicas para verificar la autenticidad de los contenidos de esos sitios. Los servidores de la red peer-to-peer XRP Ledger también comparten las actualizaciones firmadas de la lista entre ellos, reduciendo potenciales puntos de fallo. + +Técnicamente, si ejecutas un servidor, puedes configurar tu propia lista o explicitamente elegir validadores en los que confiar de forma individual, pero esto no se recomienda. Si el conjunto de validadores que has elegido no tiene suficiente superposición con otros, tu servidor podría divergir del resto de la red, y podrías perder dinero por culpa del estado divergente de tu servidor. + +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). +- Para una explicación del **diseño de decisiones y transfondo** detrás del protocolo de consenso, cer [Principios y reglas del consenso](consensus-principles-and-rules.md). +- Para **investigaciones academicas** explorando las propiedades y limitaciones del protocolo, ver [Investigación del consenso](consensus-research.md). diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-research.md b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-research.md new file mode 100644 index 0000000000..f05bcc5eb3 --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-research.md @@ -0,0 +1,19 @@ +--- +html: consensus-research.html +parent: consensus.html +seo: + 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. | + + diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md new file mode 100644 index 0000000000..dfc252f237 --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/consensus-structure.md @@ -0,0 +1,215 @@ +--- +html: consensus-structure.html +parent: consensus.html +seo: + description: Entender el rol del consenso en el XRP Ledger. +labels: + - Blockchain +--- +# Estructura de consenso + +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: + +- configuración de cada [cuenta](../accounts/index.md) +- balances de XRP y [tokens](../tokens/index.md) +- ofertas en el exchange distribuido +- configuraciones de red, como los [costes de transacción](../transactions/transaction-cost.md) y las cantidades de [reserva](../accounts/reserves.md) +- Una marca de tiempo (timestamp) + +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") + +_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") + +_Figure 2: Histórico del XRP Ledger_ + +Una versión de ledger tiene dos identificadores. Un identificador es su _ledger index_ o índice del ledger. Las versiones de ledger son numeradas incrementalmente. Por ejemplo, si la versión del ledger actual tiene un ledger index de 100, el previo tiene un ledger index 99 y el siguiente ledger tendrá index 101. El otro identificador es un _ledger hash_, el cual es una huella digital de los contenidos del ledger. + +A medida que los servidores proponen trnsacciones para aplicar en el ledger, pueden crear varias versiones del ledger con contenidos ligeramente diferentes. Estas versiones candidatas del ledger tienen el mismo ledger index pero diferentes ledger hashes. De los muchas candidatas, solo una puede ser validada. Todas las otras versiones ledger candidatas son descartadas. Por lo tanto, hay exactamente un ledger hash validado para cada ledger index en el histórico. + +Los cambios a nivel de usuario son el resultado de transacciones. Ejemplos de [transacciones](../../references/protocol/transactions/index.md) incluyen pagos, cambios de la configuración de cuenta o trust lines, y ofertas para intercambiar. Cada transacción autoriza uno o más cambios en el ledger, y está firmada criptográficmente por el dueño de la cuenta. Las transacciones son la única manera para autorizar cambios de una cuenta, o para cambiar algo más en el ledger. + +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") + +_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 + +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. + +Hay otras clases de códigos de resultado además de **`tes`** y **`tec`**. Cualquier otras clases de códigos de resultados indican fallos provisionales devueltos por las llamadas API. Solo los códigos **`tes`** y **`tec`** aparecen en los ledgers. Las transacciones que no aparecen incluidas en ledger no pueden tener efecto en el estado del ledger (incluyendo balances XRP), pero transacciones que son provisionalmente fallidas pueden acabar sucediendo. + +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. + +## 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") + +_Figura 4: Participantes en el Protocolo XRP Ledger_ + +Los servidores que reciben, transmiten y procesan transacciones pueden ser servidores de seguimiento o validadores. Las funciones principales de los servidores de seguimiento incluyen distribución de transacciones de clientes y responder a consultas sobre el ledger. Los servidores de validación realizan las mismas funciones que los servidores de seguimiento y también contribuyen a avanzar en el histórico del ledger. 3. + +Cuando se aceptan transacciones enviadas por aplicaciones de cliente, cada servidor de seguimiento utiliza el último ledger validado como punto de inicio. Las transacciones aceptadas son candidatas. Los servidores envían sus transacciones candidatas a sus pares, permitiendo a las transacciones candidatas propagarse a través de la red. Idealmente, cada transacción candidata debería ser conocida por todos los servidores, permitiendo a cada uno considerar el mismo conjunto de transacciones a aplicar al último ledger validado. Sin embargo, como las transacciones tardan tiempo en propagarse, los servidores no trabajan con el mismo conjunto de transacciones candidatas todas las veces. Para tener en cuenta esto, el XRP Ledger utiliza un proceso llamado consenso para asegurar que las mismas transacciones son procesadas y los ledger validados son consistentes a través de la red peer-to-peer XRP Ledger. + +### Consenso + +Los servidores de la red comparten información sobre transacciones candidatas. A través del proceso de consenso, los validadores agregan en un subconjunto de transacciones candidatas para ser consideradas en el siguiente ledger. El consenso es un proceso iterativo en el cual los servidores transmiten propuestas, o conjuntos de transacciones candidatas. Los servidores comunican y actualizan las propuestas hasta que haya supermayoría 4 de los validadores elegidos que acuerdan el mismo conjuntos de 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") + +_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._ + +Las transacciones candidatas que no están incluidas en la propuesta acordada siguen siendo transacciones candidatas. Pueden ser consideradas otra vez en la nueva versión del ledger. Normalmente, una transacción que ha sido omitida en una versión del ledger se incluye en la siguiente versión del ledger. + +En algunas circunstancias, una transacción puede fallar para conseguir alcanzar consenso indefinidamente. Una de esas circunstancias es si la red incrementa el [coste de transacción](../transactions/transaction-cost.md) requerido a un valor superior al que proporciona la transacción. La transacción podría ser exitosa si las comisiones se reducen en algún momento futuro. Para asegurar que una transacción tenga éxito o falle dentro de una limitada cantidad de tiempo, las transacciones se pueden preparar para caducar si no son procesadas por un determinado ledger index. Para más información, ver [Envío de transacciones confiables](../transactions/reliable-transaction-submission.md). + +### Validación + +La validación es la segunda etapa del proceso de consenso general, que verifica que los servidores tienen los mismos resultados y declara la versión final del ledger. En raras ocasiones, la primera etapa del [consenso puede fallar](consensus-principles-and-rules.md#consensus-can-fail); la validación proporciona una confirmación posterior para que los servidores puedan reconocer esto y actuar en consecuencia. + +La validación puede dividirse en aproximadamente dos partes: + +- Calcular la versión de ledger resultante del conjunto de transacciones acordado. +- Comparar resultados y declarar validada la versión del ledger si suficientes validadores confiables están de acuerdo. + +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: + +1. Empezar con el ledger validado anterior. + +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. + +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 + + 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. + +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") + +_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._ + +#### Comparar resultados + +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") + +_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._ + +Los servidores de la red reconocen una instancia ledger como validada cuando una supermayoría de pares han firmado y difundido el mismo hash de validación 7. Más adelante, las transacciones son aplicadas a este ahora ledger validado y actualizado con el ledger index N+1. + +En casos donde el servidor se encuentra en una minoría, habiendo generado un ledger que difiere de sus pares, el servidor ignora el ledger que ha generado 8. Regenera el ledger correcto, o recupera el ledger correcto según sea necesario. + +Si la red no logra un acuerdo de supermayoría sobre las validaciones, esto implica que el volumen de transacciones era muy alto o la latencia de la red es demasiado grande para que el proceso de consenso para producir propuestas consistentes. En este caso, los servidores repiten el proceso de consenso con una nueva versión del ledger. A medida que pasa el tiempo desde el consenso comenzó, es cada vez más probable que la mayoría de los servidores haya recibido el mismo conjunto de transacciones candidatas, ya que cada ronda de consenso reduce el desacuerdo. El XRP Ledger ajusta dinámicamente los [costes de transacciones](../transactions/transaction-cost.md) y el tiempo de espera para el consenso en respuesta a estas condiciones. + +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. + +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. +- 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 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. + +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. + +## 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) +- **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) +- **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][] + + + + + +## Pies de notas + +1 – Transacciones con [códigos de resultado **tec**](../../references/protocol/transactions/transaction-results/tec-codes.md) no proporcionan la acción solicitada, pero tienen efecto en el ledger. Para prevenir el abuso de la red y pagar por el coste de distribución de la transacción, destruyen el XRP del [coste de la transacción](../transactions/transaction-cost.md). Para no bloquear otras transacciones enviadas por el mismo remitente al mismo tiempo, se incrementa el [sequence number](../../references/protocol/data-types/basic-data-types.md#account-sequence) de la cuenta emisora. Transacciones con el tipo resultado `tec` a veces también realizan mantenimiento como borrar objetos caducados u ofertas de mercado sin fondos. + +2 – Por ejemplo, consideramos un escenario donde Alice tiene 100$, y envía todo a Bob. Si una aplicación primero envía esa transacción de pago, entonces inmediatamente tras comprobar el balance de Alice, la API devuelve 0$. Este valor está basado en el resultado provisional de una transacción candidata. Hay circunstancias en las cuales el pago falla y el balance de Alice se mantiene a 100$ (o, debido a otras transacciones, se convierte en otra cantidad). El único método para conocer con certeza que el pago de Alice a Bob ha ocurrido es comprobar el estado de la tranacción hasta que está en el ledger validado y además el código de resultado es **`tesSUCCESS`**. Si la transacción está en un ledger validado con cualquier otro código resultado, el pago ha fallado. + +3 – Hablando estríctamente, los validadores son un subconjunto de servidores de seguimiento. Proporcionan las mismas características y adicionalmente envían mensajes de "validación". Los servidores de seguimiento pueden clasificarse según si mantienen el histórico del ledger parcial o completo. + +4 – Transacciones que fallan en pasar la ronda de consenso cuando el porcentaje de pares que reconoce la transacción cae por debajo del umbral. Cada ronda es un proceso iterativo. Al principio de la primera ronda, al menos el 50% de pares deben estar de acuerdo. El umbral final para la ronda de consenso es un 80% de acuerdo. Estos valores específicos estan sujetos a cambio. + +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). + +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. + +8 – En la práctica, el servidor detecta que está en una minoría antes de recibir las validaciones de todos los pares. Lo sabe cuando recibe validaciones no coincidentes de más del 20% de pares que su validación no puede alcanzar el 80% del umbral. En ese momento, puede empezar a recalcular su ledger. + +9 – En la práctica, el XRP Ledger corre más eficientemente empezando una nueva ronda de consenso al mismo timepo, antes de que la validación se haya completado. + +10 – Un servidor `rippled` puede responder a las peticiones API incluso sin tener un histórico del ledger completo. Interrupciones en el servicio o en la conectividad de la red puede llevar a ledgers perdidos, o a lagunas, en el histórico del ledger del servidor. Con el tiempo, si se configura así, `rippled` llena los vacíos en su histórico. Cuando prueba transacciones perdidas, es importante verificar contra un servidor con ledgers completos continuos desde que la transacción que se ha enviado hasta su `LastLedgerSequence`. Utiliza el [método server_info][] para determinar qué ledgers están disponibles para un servidor en partícular. + +{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/fee-voting.md b/@i18n/es-ES/docs/concepts/consensus-protocol/fee-voting.md new file mode 100644 index 0000000000..30488760a9 --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/fee-voting.md @@ -0,0 +1,67 @@ +--- +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). +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. + +Los operadores de [validadores `rippled`](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md) pueden configurar sus preferencias para el coste de transacción y los requisitos de reserva en el apartado de `[voting]` del fichero `rippled.cfg`. + +**Atención:** Los requisitos insuficientes, en caso de ser adoptados por un consenso de validadores confiables, podrían exponer a la red peer-to-peer XRP Ledger a ataques de denegación de servicio. + +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. | `10000000` (10 XRP) | +| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `2000000` (2 XRP) | + +## 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. + +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. + +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. + +## 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 | + + +## 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) +- **Tutoriales:** + - [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][] + +{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/index.md b/@i18n/es-ES/docs/concepts/consensus-protocol/index.md new file mode 100644 index 0000000000..567a85925f --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/index.md @@ -0,0 +1,72 @@ +--- +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. +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: + +- Todos los que utilizan el XRP Ledger pueden ponerse de acuerdo en el último estado, y qué operaciones se han producido y en qué orden. +- Todas las transacciones válidas son procesadas sin necesidad de un operador central o sin tener un único punto de fallo. +- El ledger puede progresar incluso si algunos participantes se incorporan, se marchan o tienen un comportamiento inapropiado. +- Si demasiados participantes son incontactables o se comportan inadecuadamente, la red fallará a la hora de progresar en vez de divergir o confirmar transacciones inválidas. +- Confirmar transacciones no requiere un uso de recursos competitivos o malgastados, como en muchos otros sistemas blockchains. + +Estas propiedades se resumen a veces en los siguientes principios, en orden de prioridad: **Correción, Acuerdo, Progreso**. + +Este protocolo sigue evolucionando, al igual que nuestro conocimiento de sus límites y posibles casos de fallo. Para investigaciones academicas del protocolo en sí, ver [Investigación del consenso](consensus-research.md). + +## Trasfondo + +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: + +- El estado actual de todos los balances y objetos guardados en el 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") + +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") + +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 + +1. Debido a un percance ocurrido al inicio de la historia de XRP Ledger, [se perdieron los ledgers del 1 al 32569](http://web.archive.org/web/20171211225452/https://forum.ripple.com/viewtopic.php?f=2&t=3613). (Esta pérdida representa aproximadamente la primera semana de la historia del ledger.) Por lo tanto, el ledger #32570 es el ledger más antiguo disponible. Porque el estado del XRP Ledger se guarda en cada versión de cada ledger, el ledger puede continuar sin la historia perdida. Las nuevas redes de prueba seguirán empezando con el índice del ledger 1. + +2. En Bitcoin, el estado actual a veces se llama conjunto de "UTXOs" (salidas de transacción no gastadas). A diferencia que el XRP Ledger, un servidor Bitcoin debe descargar el histórico completo de transacciones para conocer el conjunto completo de UTXOs y procesar nuevas transacciones. Desde 2018, ha habido varias propuestas para modificar el mecanismo de consenso de Bitcoin para periódicamente resumir las últimas UTXOs para que los nuevos servidores no necesiten hacerlo. Ethereum utiliza un enfoque similar al del XRP Ledger, con un resumen del estado actual (conocido como _state root_) en cada bloque, pero la sincronización tarda más en Ethereum porque almacena más información en su estado de datos. + +3. Un servidor no necesita una conexión directa con sus validadores de confianza para escucharlos. La red peer-to-peer del XRP Ledger utiliza un _protocolo de cotilleo_ donde los servidores se identifican entre ellos con una clave pública y transmiten mensajes firmados digitalmente por otros. diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md b/@i18n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md new file mode 100644 index 0000000000..774991aade --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/invariant-checking.md @@ -0,0 +1,172 @@ +--- +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. +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. + +Como muchas características de seguridad, todos esperamos que la comprobación de invariantes nunca necesite hacer nada. Sin embargo, puede ser útil entender las invariantes del XRP Ledger porque definen los límites estrictos del procesamiento de transacciones en el XRP Ledger, y reconocer el problema en el improbable caso que una transacción falle porque ha violado una comprobación de invariantes. + +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. +- El coste de la ejecutar incorrectamente una transacción es alto y no es aceptable bajo ningún estándar. + +Específicamente, la ejecución de transacciones incorrectas podría crear datos inválidos o corruptos que luego hagan que servidores en la red fallen consistentemente en un estado "imposible" que pudiese detener toda la red. + +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: + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "Fuente") + +- [Comprobación de coste de transacción](#comprobación-de-coste-de-transacción) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "Fuente") + +- [XRP no creado](#xrp-no-creado) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "Fuente") + +- [Account Roots no eliminadas](#account-roots-no-eliminadas) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "Fuente") + +- [Comprobaciones de balance XRP](#comprobaciones-de-balance-XRP) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "Fuente") + +- [Coincidencia de tipos de entradas ledger](#coincidencia-de-tipos-de-entradas-de-ledger) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "Fuente") + +- [No XRP Trust Lines](#no-xrp-trust-lines) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "Fuente") + +- [No malas ofertas](#no-malas-ofertas) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "Fuente") + +- [No escrow cero](#no-escrow-cero) + +[[Fuente]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "Fuente") + +- [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. + + +### 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). + + +### 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. + + +### 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. + + +### 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). + + +### 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. + + +### 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. + + +### 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. + + +### 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). + +### 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. + +### 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. + +## Ver también + +- **Blog:** + - [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) + + +- **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) + +{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/@i18n/es-ES/docs/concepts/consensus-protocol/negative-unl.md b/@i18n/es-ES/docs/concepts/consensus-protocol/negative-unl.md new file mode 100644 index 0000000000..1fe6d50962 --- /dev/null +++ b/@i18n/es-ES/docs/concepts/consensus-protocol/negative-unl.md @@ -0,0 +1,178 @@ +--- +html: negative-unl.html +parent: consensus.html +seo: + 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)._ + +La _UNL negativa_ es una característica del [protocolo de consenso](index.md) del XRP Ledger que mejora la _viveza_, la habilidad de la red a seguir progresando hacia adelante durante una interrupción parcial. Utilizando la UNL negativa, los servidores ajustan sus UNLs efectivas en función de los validadores que están actualmente en línea y operativos, de modo que una nueva [versión ledger](../ledgers/index.md) puede ser declarada _validada_ incluso si varios validadores confiables están offline. + +La UNL negativa no tiene impacto en cómo la red procesa los resultados de las transacciones o en los resultados de las transacciones, excepto que mejora la habilidad de la red para declarar resultados finales durante algunos tipos de interrupciones parciales. + +## Transfondo + +Cada servidor en el protocolo XRP Ledger tiene su propia UNL (Lista de Nodos Únicos), una lista de validadores en los que se confía para no colisionar, y cada servidor decide independientemente cuándo se valida una versión del ledger basándose en el consenso cuando suficientes de sus validadores confiables están de acuerdo en una nueva versión del ledger. (La configuración predeterminada utiliza una UNL recomendada, firmada por Ripple, que consiste en validadores que Ripple considera suficientemente únicos, confiables e independientes). El requisito del cuórum estándar es que al menos el 80% de los validadores confiables deben estar de acuerdo. + +Si más del 20% de los validadores confiables se desconectan o no pueden comunicarse con el resto de la red, la red deja de validar nuevos ledgers porque no puede alcanzar un cuórum. Esta es una elección de diseño para garantizar que los resultados de las transacciones no puedan cambiarse después de que se declaren definitivos. Durante dicha situación, los servidores restantes seguirían en línea y podrían proporcionar datos de transacciones pasadas y tentativas, pero no podrían confirmar el resultado final, inmutable, de nuevas transacciones. + +Sin embargo, esto significa que la red podría dejar de avanzar si algunos validadores ampliamente confiables se desconectaran. A partir del 6 de octubre de 2020, hay 34 validadores en la UNL recomendada de Ripple, por lo que la red dejaría de avanzar si 7 o más de ellos estuvieran desconectados. Además, si uno o dos validadores están desconectados por un período prolongado, la red tiene menos margen para el desacuerdo entre los validadores restantes, lo que puede hacer que tarde más en alcanzar un consenso. + +## Resumen + +No es razonable esperar que un conjunto diverso de validadores mantenga un tiempo de actividad del 100%: muchas cosas pueden hacer que un validador se vuelva temporalmente indisponible, como: mantenimiento de hardware, actualizaciones de software, problemas de conectividad a Internet, ataques dirigidos, errores humanos, fallos de hardware y circunstancias externas como desastres naturales. + +La "UNL negativa" es una **lista de validadores de confianza que se cree que están desconectados o con mal funcionamiento**, según lo declarado por un consenso de los validadores restantes. Los validadores en la UNL negativa son ignorados para determinar si una nueva versión del ledger ha alcanzado un consenso. + +Cuando un validador que está en la UNL negativa vuelve a estar en línea y envía votos de validación consistentes, los validadores restantes lo eliminan de la UNL negativa después de un tiempo corto. + +En casos donde los validadores se desconecten uno o dos a la vez, los validadores restantes pueden usar la UNL negativa para ajustar gradualmente sus UNL efectivas, de modo que la red solo necesite el 80% de los validadores _en línea_ para alcanzar un cuórum. Para evitar que la red se fragmente, el cuórum tiene un mínimo estricto del 60% de los validadores _totales_. + +Si más del 20% de los validadores de repente se desconectan todos a la vez, los servidores restantes no pueden alcanzar el quórum necesario para validar un nuevo ledger, por lo que no se podrían validar nuevos ledgers. Sin embargo, esos servidores aún pueden avanzar tentativamente a través de rondas de consenso sucesivas. Con el tiempo, los validadores restantes continuarían aplicando cambios a la UNL negativa a los ledgers tentativos y ajustarían sus UNL efectivas; eventualmente, si la situación persiste, la red podría reanudar la validación completa de ledgers utilizando la UNL negativa ajustado de las versiones de ledgers tentativas. + +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: + +> Fiabilidad = Va ÷ 256 + +Va es el número total de votos de validación recibidos de un validador en los últimos 256 ledgers que coincidieron con la vista de consenso del servidor. + +Esta métrica de fiabilidad mide la disponibilidad de un validador _y_ el comportamiento de ese validador. Un validador debería tener una puntuación de fiabilidad alta si está sincronizado con el resto de la red y sigue las mismas reglas de protocolo que el servidor que lo califica. La puntuación de fiabilidad de un validador puede verse afectada por cualquiera de las siguientes razones: + +- Los votos de validación del validador no están llegando al servidor debido a una mala conectividad de red entre ellos. +- El validador deja de funcionar o se sobrecarga. +- El validador no sigue las mismas reglas de protocolo que el servidor, por diversas razones. Las posibilidades incluyen una mala configuración, errores de software, seguir intencionalmente una [red distinta](../networks-and-servers/parallel-networks.md), o un comportamiento malicioso. + +Si la fiabilidad de un validador es **inferior al 50%**, es candidato para ser agregado al Negative UNL. Para ser eliminado de la UNL negativa, la fiabilidad de un validador debe ser **superior al 80%**. + +Cada servidor, incluidos los validadores, calcula de forma independiente las puntuaciones de fiabilidad para todos sus validadores confiables. Diferentes servidores pueden llegar a diferentes conclusiones sobre la fiabilidad de un validador, ya sea porque los votos de ese validador llegaron a un servidor y no al otro, o porque desacordaban sobre ledgers específicos con más o menos frecuencia. Para añadir o eliminar un validador en la UNL negativa, se debe lograr un consenso de los validadores confiables sobre si un validador en particular está por encima o por debajo del umbral de fiabilidad. + +**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). + +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/pseudo-transaction-types.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). +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/pseudo-transaction-types.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. + +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. + +Este mecanismo tiene varias propiedades útiles: + +- Utiliza información que está fácilmente disponible para todos los servidores y se puede calcular rápidamente. +- 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. + +**Nota:** La UNL negativa ajusta el número _total_ de validadores de confianza a partir del cual se calcula el cuórum, no el cuórum directamente. El cuórum es un porcentaje pero el número de votos es un número entero, por lo que reducir el total de validadores de confianza no siempre cambia el número de votos requeridos para alcanzar un cuórum. Por ejemplo, si hay 15 validadores en total, el 80% es exactamente 12 validadores. Si reduces el total a 14 validadores, el 80% es 11.2 validadores, lo que significa que aún se requieren 12 validadores para alcanzar un cuórum. + +La UNL negativa no tiene impacto en otras partes del proceso de consenso, como la elección de qué transacciones incluir en el conjunto de transacciones propuestas. Esos pasos siempre se basan en la UNL configurada, y los umbrales se basan en cuántos validadores de confianza están participando activamente en la ronda de consenso. Incluso un validador que esté en la UNL negativa puede participar en el proceso de consenso. + +### Ejemplo + +El siguiente ejemplo demuestra cómo afecta la UNL negativa al proceso de consenso: + +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.") + +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.") + + +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.") + +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.") + +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.") + +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.") + +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.") + +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.") + + +## Ver también + +- **Conceptos:** + - [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) +- **Referencias:** + - [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" /%}