[es-ES] ledgers folder translated

[es-ES] ledgers folder translated

@i18n/es-ES/docs/concepts/ledgers/index.md

@@ -29,7 +29,7 @@ Una versión del ledger consta de varias partes:
 
 ## Ver también
 
-- Para más información sobre las cabeceras de ledger, IDs de objetos del ledger, y tipos de objetos del ledger, cer [Formatos de datos del ledger](../../references/protocol/ledger-data/index.md)
+- Para más información sobre las cabeceras de ledger, IDs de objetos del ledger, y tipos de objetos del ledger, ver [Formatos de datos del ledger](../../references/protocol/ledger-data/index.md)
 - Para información de cómo los servidores rastrean el historial de cambios del estado del ledger, ver [Historia del ledger](../networks-and-servers/ledger-history.md)
 
 {% raw-partial file="/docs/_snippets/common-links.md" /%}

@i18n/es-ES/docs/concepts/ledgers/ledger-close-times.md

@@ -0,0 +1,41 @@
+---
+html: ledger-close-times.html
+parent: ledgers.html
+seo:
+    description: Cómo el XRP Ledger calcula el valor de tiempo de cierre para cada versión del ledger.
+labels:
+  - Blockchain
+---
+# Tiempos de cierre del ledger
+
+La hora exacta en la que la versión del ledger se ha cerrado se queda guardada en el campo `close_time` de la cabecera del ledger o [ledger header](../../references/protocol/ledger-data/ledger-header.md). Para hacer más facil a la red llegar a un consenso en un tiempo de cierre exacto, este valor es redondeado a un número de segundos basado en el momento de resolución del cierre, actualmente 10 segundos. Si redondear causase a un tiempo de cierre ser igual que (o anterior) a su ledger padre, el ledger hijo tendrá su tiempo de cierre igual al tiempo de cierre del ledger padre más 1. Esto garantiza que los tiempos de cierre de los ledgers validados son estríctamente incrementales. <!-- STYLE_OVERRIDE: a number of -->
+
+Dado que las nuevas versiones de ledgers se suelen cerrar cada 3 a 5 segundos, estas reglas resultan en un patrón laxo donde el tiempo de cierre de los ledgers termina en :00, :01, :02, :10, :11, :20, :21, y demás. Los tiempos terminados en 2 son menos comunes y los tiempos terminados en 3 son muy raros, pero ambos pueden ocurrir aleatoriamente cuando más ledgers aleatoriamente cierran en ventanas de 10 segundos.
+
+Generalmente hablando, el ledger no puede realizar medidas basadas en el tiempo que la resolución del tiempo de cierre. Por ejemplo, para comprobar si un objeto ha pasado su fecha de caducidad, se utiliza la regla para compararlo con el tiempo de cierre del ledger padre. (El tiempo de cierre de un ledger no es conocido todavía cuando está ejecutando transacciones para introducir en ese ledger.) Esto quiere decir que, por ejemplo, un [Escrow](../payment-types/escrow.md) podría finalizar satisfactoriamente en un momento de la vida real que es 10 segundos después de la caducidad basada en el tiempo especificado en el objeto del Escrow.
+
+### Ejemplo
+
+Los siguientes ejemplos muestran el comportamiento de redondeo en los tiempos de cierre del ledger, desde la perspectiva de un validador por ejemplo, siguiendo un ledger con el tiempo de cierre **12:00:00**:
+
+**Ronda actual de consenso**
+
+1. Un validador observa que eran las **12:00:03** cuando el ledger cierra y entra en consenso. El validador incluye este tiempo de cierre en sus propuestas.
+2. El validador observa que la mayoría de otros validadores (en su UNL) propusieron un tiempo de cierre de 12:00:02, y otro ha propuesto un tiempo de cierre de 12:00:03. Esto cambia su tiempo de cierre propuesto para que coincida con el del consenso de **12:00:02**.
+3. El validador redondea su valor al intervalo de tiempo de cierre más cercano, resultando en **12:00:00**.
+4. Como 12:00:00 no es mayor que el tiempo de cierre del ledger anterior, el validador ajusta el tiempo de cierre para ser exactamente 1 segundo después del tiempo de cierre del anterior ledger. El resultado es un tiempo de cierre ajustado a **12:00:01**.
+5. El validador construye el ledger con estos detalles, calcula el hash resultante, y confirma en el paso de validación lo que otros hicieron del mismo modo.
+
+Los servidores que no validan hacen todos los mismos pasos, exceptuando que no proponen sus tiempos de cierre registrados al resto de la red.
+
+**Siguiente ronda de consenso**
+
+1. El siguiente ledger entra en consenso a las **12:00:04** de acuerdo con la mayoría de los validadores.
+2. Esto vuelve a redondear hacia abajo otra vez, a un tiempo de cierre de **12:00:00**.
+3. Como no es mayor al anterior tiempo de cierre del ledger anterior de las 12:00:01, el tiempo de cierre ajustado es **12:00:02**.
+
+**La siguiente ronda después de esa**
+
+1. El siguiente ledger entra en consenso a las **12:00:05** de acuerdo con la mayoría de validadores.
+2. Esto se redondea hacia arriba, según la resolución de tiempo de cierre, a las **12:00:10**.
+3. Como el valor es mayor que el tiempo de cierre del ledger anterior, no necesita ser ajustado. **12:00:10** se convierte en la hora de cierre oficial.

@i18n/es-ES/docs/concepts/ledgers/ledger-structure.md

@@ -0,0 +1,70 @@
+---
+html: ledger-structure.html
+parent: ledgers.html
+seo:
+    description: Un vistazo más cercano a los elementos de un bloque de ledger individual.
+---
+# La estructura del ledger
+
+El XRP Ledger es una blockchain, lo que quiere decir que consiste en un histórico de bloques de datos consecutivos. Un bloque en la blockchain XRP Ledger se denomina una _versión del ledger_ o _ledger_ abreviado.
+
+El protocolo de consenso toma la última versión del ledger como punto de partida, forma un acuerdo entre los validadores sobre un conjunto de transacciones para aplicar a continuación, después confirma que todo el mundo obtuvo los mismos resultados aplicando esas transacciones. Cuando esto ocurre satisfactoriamente, el resultado es una nueva versión de un ledger _validado_. Desde aquí, el proceso se repite para construir la próxima versión del ledger.
+
+Cada versión del ledger contiene _datos de estado_, un _conjunto de transacciones_, y una _cabecera_ que contiene metadatos.
+
+[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg "Diagrama: Un ledger está formado por una cabecera, un conjunto de transacciones, y datos de estado.")
+
+
+## Estado de datos
+
+[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg "Diagrama: Los datos de estado de un ledger, en forma de varios objetos los cuales a veces están unidos como en un grafo.")
+
+Los _datos de estado_ representan una fotografía de todas las cuentas, balances, configuraciones, y otra información de esta versión del ledger. Cuando un servidor se conecta a la red, una de las primeras cosas que hace es descargar un conjunto completo de los datos de estado actuales para poder procesar nuevas transacciones y responder consultas sobre el estado actual. Como cada servidor de la red tiene una copia completa de los datos del estado, todos los datos son públicos y cada copia es igualmente válida.
+
+Los datos de estado consisten en objetos individuales llamados _entradas de ledger_, almacenados en un formato de árbol. Cada entrada del ledger tiene un ID único 256-bit que puedes usar para buscar en el árbol de estado.
+
+## Conjunto de transacciones
+
+[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg "Diagrama: Un conjunto de transacciones del ledger, un grupo de transacciones organizado en orden canónico.")
+
+Cada cambio realizado en el ledger es el resultado de una transacción. Cada versión del ledger contiene un _conjunto de transacciones_ que es un grupo de transacciones que se han aplicado recientemente en un orden específico. Si tomas los datos de estado de la versión anterior del ledger y aplicas este conjunto de transacciones del ledger encima de él, obtienes los datos de estado de este ledger como resultado.
+
+Cada transacción en el conjunto del ledger tiene ambas de la siguientes partes:
+
+- _Instrucciones de la transaccion_ mostrando lo que el remitente le pidió hacer.
+- _Metadatos de la transacción_ mostrando exáctamente cómo la transacción debe ser procesada y cómo afecta a los datos de estado del ledger.
+
+
+## Cabecera del ledger
+
+La _cabecera del ledger_ es un bloque de datos que resume la versión del ledger. Como la portada de un informe, identifica de forma única la versión del ledger, enumera sus contenidos, y muestra la hora en la que se creó, junto con algunas otras notas. La cabecera del ledger contiene la siguiente información:
+
+<!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->
+
+- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg "") El _ledger index_, o índice del ledger identifica la posición del ledger en la cadena. Se construye en el ledger con un índice             restando uno, hasta llegar hasta el punto de inicio llamado como el _genesis ledger_. Esto forma un histórico público con todas las trnasacciones y resultados.
+- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg "") El _ledger hash_, que identifica de manera única los contenidos del ledger. El hash es calculado de manera que si cambia algún detalle, la versión del ledger cambia, el hash es completamente diferente, lo que lo convierte también en un checksum que muestra que ninguno de los datos en el ledger se ha perdido, modificado, o corrompido.
+- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg "") El _parent ledger hash_ o el hash del ledger padre. Una versión del ledger es definida en gran parte por la diferencia con el _parent ledger_ que viene antes de el, por lo que la cabecera también contiene el hash único para su ledger padre.
+- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg "") El _close time_ u hora de cierre, la timestamp que marca cuando se finalizaron los contenidos del ledger. Este número se redondea por un número de segundos, generalmente 10.
+- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg "") Un _hash de datos del estado_ el cual actua de checksum para los datos del estado.
+- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg "") Un _hash del conjunto de transacciones_ el cual actua como checksum de los datos del conjuntos de transacciones.
+- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg "") Algunas otras notas como la cantidad total de XRP en existencia y la cantidad que se redondeó la hora de cierre.
+
+Un conjunto de transacciones y los datos de estado son ilimitados en espacio, pero la cabecera del ledger siempre es de un tamaño fijo. Para los datos exactos y el formato binario de una cabecera del ledger, ver [Cabecera del leder](../../references/protocol/ledger-data/ledger-header.md).
+
+
+## Estado de validación
+
+[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg "Diagrama: Un estado de validación de un ledger, el cual es añadido encima del ledger y no es parte del ledger en sí.")
+
+Cuando un consenso de la Lista de Nodos Únicos de un servidor está de acuerdo en los contenidos de una versión del ledger, esa versión del ledger es marcada como validada e inmutable. Los contenidos del ledger solo pueden cambiar mediante transacciones posteriores que creen una nueva versión del ledger, continuando la cadena.
+
+Cuando una versión del ledger es creada por primera vez, no está todavía validada. Debido a las diferencias en cuanto llegan las transacciones a diferentes servidores, la red puede construir y proponer múltiples versiones diferentes del ledger para ser el siguiente en la cadena. El [protocolo de consenso](../consensus-protocol/index.md) decide cual de ellas se valida. (Las transacciones candidatas que no estén en la versión del ledger validado pueden generalmente incluirse en el conjunto de transacciones la siguiente versión del ledger en su lugar.)
+
+
+## ¿Índice del ledger o Hash del ledger?
+
+Hay dos formas diferentes de identificar la versión del ledger: Su _ledger index_ o índice del ledger y su _ledger hash_ o hash del ledger. Estos dos campos identifican un ledger, pero tienen propósitos distintos. El índice del ledger te informa de la posición del ledger en la cadena, y el hash del ledger refleja los contenidos del ledger.
+
+Ledgers de diferentes cadenas pueden tener el mismo índice ledger pero distintos hashes. Además, al tratar con versiones del ledger no validadas, puede haber múltiples ledgers candidatos con el mismo índice pero contenidos diferentes y, por lo tanto, hashes diferentes.
+
+Dos ledgers con el mismo hash ledger son siempre completamente idénticos.

@i18n/es-ES/docs/concepts/ledgers/open-closed-validated-ledgers.md

@@ -0,0 +1,24 @@
+---
+html: open-closed-validated-ledgers.html
+parent: ledgers.html
+seo:
+    description: Los objetos del ledger tienen uno de los tres estados — abierto, cerrado, o validado.
+labels:
+  - Blockchain
+---
+# Ledgers abiertos, cerrados, y validados
+
+El servidor `rippled` hace una distinción entre versiones de ledgers que están _abiertas_, _cerradas_, y _validadas_. Un servidor tiene un ledger abierto, cualquier número de ledgers cerrados pero no validados, y un historial inmutable de ledgers validados. La siguiente tabla resume las diferencias:
+
+| Tipo de ledger:                     | Abierto                        | Cerrado                                     | Validado |
+|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
+| **Propósito:**                     | Espacio de trabajo temporal         | Próximo estado propuesto                        | Estado previo confirmado |
+| **Número usado:**                 | 1                           | Cualquier número, normalmente 0 o 1             | Uno por ledger index, crece con el tiempo |
+| **¿Pueden los contenidos cambiar?**         | Sí                         | No, pero el ledger completo se podría reemplazar | Nunca |
+| **Transacciones se aplican en:** | El orden que son recibidas | Orden canónico                            | Orden canónino |
+
+No intuitivamente, el XRP Ledger nunca "cierra" un ledger abierto para convertirlo en un ledger cerrado. En cambio, el servidor descarta el ledger abierto, crea un nuevo ledger cerrado aplicando transacciones encima de los ledgers cerrados previos, entonces crea un nuevo ledger abierto utilizando el último ledger cerrado como base. Esto es una consecuencia de [cómo el consenso resuelve el problema del doble gasto](../consensus-protocol/consensus-principles-and-rules.md#simplificando-el-problema).
+
+Para un ledger abierto, los servidores aplican transacciones en el orden en el que esas transacciones aparecen, pero diferentes servidores puede que vean transacciones en diferentes órdenes. Como no hay un vigilante del tiempo para decidir qué transacción fue actualmente la primera, los servidores pueden no estar de acuerdo en el orden exacto de las transacciones que fueron enviadas casi al mismo tiempo. Por lo tanto, el proceso para calcular una versión de ledger cerrado que es elegible para [validación](../consensus-protocol/consensus-structure.md#validación) es diferente que el proceso de construir un ledger abierto con transacciones propuestas en su orden de llegada. Para crear un ledger "cerrado", cada servidor XRP Ledger comienza con un cojunto de transacciones y una versión anterior de ledger, o "padre". El servidores pone las transacciones en orden canónico, después las aplica al anterior ledger en ese orden. El orden canónico está diseñado para ser determinístico y eficiente, pero dificil de manipular, para incrementar la dificultad de adelantarse (o front-running) a las Ofertas en el [exchange descentralizado](../tokens/decentralized-exchange/index.md).
+
+Por lo tanto, un ledger abierto es solo utilizado como un espacio de trabajo temporal, lo cual es una de las principales razones por las cuales  [los resultados tentativos pueden variar de los resultados finales](../transactions/finality-of-results/index.md) en las transacciones.