mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 20:05:50 +00:00
Merge branch 'master' into amm-passive-income
This commit is contained in:
oeggert
2
.gitignore
vendored
2
.gitignore
vendored
@@ -8,5 +8,7 @@ yarn-error.log
|
||||
*.iml
|
||||
.venv/
|
||||
|
||||
_code-samples/*/js/package-lock.json
|
||||
|
||||
# PHP
|
||||
composer.lock
|
||||
|
||||
48
@i18n/es-ES/CODE_OF_CONDUCT.md
Normal file
48
@i18n/es-ES/CODE_OF_CONDUCT.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Código de conducta del pacto de contribuidores
|
||||
|
||||
## Nuestro compromiso
|
||||
|
||||
Con el fin de fomentar un ambiente abierto y acogedor, nosotros, como contribuidores y mantenedores, nos comprometemos a hacer de la participación en nuestro proyecto y nuestra comunidad una experiencia libre de acoso para todos, independientemente de, entre otras, características como la edad, tamaño corporal, discapacidad, origen étnico, características sexuales, identidad y expresión de género, nivel de experiencia, educación, estatus socioeconómico, nacionalidad, apariencia personal, raza, religión o identidad y orientación sexual.
|
||||
|
||||
## Nuestros estándares
|
||||
|
||||
Ejemplos de comportamiento que contribuyen a crear un ambiente positivo incluyen:
|
||||
|
||||
* Utilizar lenguaje acogedor e inclusivo
|
||||
* Ser respetuoso con los diferentes puntos de vista y experiencias
|
||||
* Saber aceptar las críticas constructivas
|
||||
* Centrarse en lo que es lo mejor para la comunidad
|
||||
* Mostrar empatía hacia otros miembros de la comunidad
|
||||
|
||||
Ejemplos de comportamiento que no contribuyen a crear un ambiente positivo incluyen:
|
||||
|
||||
* Utilizar un lenguaje o imágenes sexualizadas y atención o insinuaciones sexuales no deseadas
|
||||
* Trolear, comentario insultantes/peyorativos y ataques personales o políticos
|
||||
* Acoso público o en privado
|
||||
* Publicar información privada de otras personas, así cómo direcciones físicas o electrónicas, sin permiso explícito
|
||||
* Cualquier otra conducta que pueda ser razonablemente considerada inapropiada en un sentido profesional
|
||||
|
||||
## Nuestras responsabilidades
|
||||
|
||||
Los mantenedores del proyecto son responsables de aclarar los estándares de comportamiento aceptable y se espera que tomen acciones correctivas justas y apropiadas en respuesta a cualquier caso de comportamiento inaceptable.
|
||||
|
||||
Los mantenedores del proyecto tienen el derecho y la responsaiblidad de eliminar, editar o rechazar comentarios, commits, código, ediciones de wiki, problemas y otras contribuciones que no estén alineadas con este Código de Conducta, o de expulsar temporal o definitivamente a cualquier colaborador por otros comportamientos que consideren inapropiados, amenazantes, ofensivos, dañinos o que viole de cualquier modo este Código de Conducta.
|
||||
|
||||
## Alcance
|
||||
|
||||
Este Código de Conducta aplica en todos los espacios del proyecto y también aplica cuando un individuo está representando el proyecto o su comunidad en espacios públicos. Ejemplos de representación de un proyecto o la comunidad incluye usar un correo electrónico oficial del proyecto, publicaciones a través de una cuenta oficial de redes sociales o actuar como representante asignado en un evento en línea o en la vida real. La representación de un proyecto debe ser definida y aclarada con más detalle por los mantenedores del proyecto.
|
||||
|
||||
## Aplicación
|
||||
|
||||
Los casos de comportamiento abusivo, acoso, o de cualquier otro modo inaceptable se pueden informar contactando con el equipo del proyecto al correo <ripplex@ripple.com>. Todas las quejas serán revisadas e investigadas y resultarán en una resupuesta que se considere adecuada y necesaria a las circunstancias. El equipo del proyecto está obligado a mantener la confidencialidad con respecto al informador del incidente. Podría darse el caso de publicar más detalles sobre políticas de comportamiento específicas.
|
||||
|
||||
Los mantenedores de proyecto que no sigan o hagan cumplir el Código de conducta de buena fe podrían enfrentarse a repercusiones temporales o definitivas según lo determinen otros miembros que lideren el proyecto.
|
||||
|
||||
## Atribución
|
||||
|
||||
Este Código de Conducta está adaptado de el [Pacto del Contribuidores][inicio], versión 1.4, disponible en https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
||||
|
||||
[inicio]: https://www.contributor-covenant.org
|
||||
|
||||
Para respuestas a preguntas comunes sobre este código de conducta, visita
|
||||
https://www.contributor-covenant.org/faq
|
||||
3
@i18n/es-ES/CONTRIBUTING.md
Normal file
3
@i18n/es-ES/CONTRIBUTING.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# Contribuir
|
||||
|
||||
Para obtener información sobre cómo contribuir a este repositorio, consulta [Contribute Documentation (XRPL.org)](https://xrpl.org/es_ES/contribute-documentation.html).
|
||||
151
@i18n/es-ES/about/faq.md
Normal file
151
@i18n/es-ES/about/faq.md
Normal file
@@ -0,0 +1,151 @@
|
||||
---
|
||||
seo:
|
||||
description: Respuestas a preguntas frecuentes sobre el XRP Ledger, el ecosistema XRPL y la comunidad.
|
||||
subtitle: Respuestas a tus preguntas XRPL
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
###### FAQ
|
||||
# Respuestas a Tus Preguntas XRPL
|
||||
|
||||
<!--#{ Use H4s for questions and H2s for sections. This keeps the sidebar nav from getting too clustered and allows the faq filter to stylize things as an accordion. #}-->
|
||||
|
||||
#### ¿Es XRPL una blockchain privada, propiedad de Ripple?
|
||||
|
||||
No, el XRP Ledger es una blockchain pública y descentralizada. Cualquier cambio que impactase al proceso de las transacciones o al consenso necesita ser aprobado por al menos el 80%% de la red. Ripple es un contribuidor de la red, pero sus derechos son los mismos que los de otros contruibuidores. En términos de validación, hay más de 150 validadores en la red con más de 35 en la Lista de Nodos Únicos (ver [“¿Qué son las Listas de Nodos Únicos (UNLs en inglés)?” abajo](#what-are-unique-node-lists-unls)) — Ripple mantiene [solo 1](https://foundation.xrpl.org/2023/03/23/unl-update-march-2023/) de esos nodos.
|
||||
|
||||
#### ¿No es la Prueba de Trabajo (Proof of Work) el mejor mecanísmo de validación?
|
||||
|
||||
La Prueba de Trabajo (PoW en inglés) fue el primer mecanismo para resolver el problema del doble gasto sin requerir a un tercero de confianza. [El mecanismo de consenso del XRP Ledger](../docs/concepts/consensus-protocol/index.md) resuelve el mismo problema de una manera mucho más rápida, barata y energéticamente más eficiente.
|
||||
|
||||
#### ¿Cómo puede ser una blockchain sostenible?
|
||||
|
||||
Se sabe abiertamente que el consumo de energia de Bitcoin, a partir de 2021, es equivalente al utilizado por Argentina, mucha de la electricidad que usan los mineros de Bitcoin procede de fuentes contaminantes. El XRP Ledger confirma transacciones a través del mecanismo de “[consenso](../docs/concepts/consensus-protocol/index.md)” - el cual no desperdicia energía como lo hace la prueba de trabajo - y aprovecha las compensaciones de carbono para ser [una de la primeras blokchains verdaderamente neutral en carbono](https://ripple.com/ripple-press/ripple-leads-sustainability-agenda-to-achieve-carbon-neutrality-by-2030/).
|
||||
|
||||
#### ¿Pueden otras divisas que no sean XRP ser intercambiadas a través del XRPL?
|
||||
|
||||
Sí, el XRP Ledger fue creado específicamente para poder tokenizar activos arbitrarios, como el USD, EUR, petróleo, oro, puntos de fidelización, y más. Cualquier divisa puede ser emitida en el XRP Ledger. Esto se ilustra en la creciente comunidad que respalda una variedad de tokens cripto y fiat.
|
||||
|
||||
#### ¿No es XRPL solo para pagos?
|
||||
|
||||
Aunque XRPL inicialmente se desarrolló para casos de uso de pagos, tanto el libro mayor como el activo nativo digital XRP se han ido popularizando para un rango de casos de uso innovadores como los NFTs. Nuevas propuestas de estándares para un creador de mercados automatizado (en inglés, AMM), la enmienda de los "hooks" para la funcionalidad de contratos inteligentes, y puentes entre cadenas están siendo desarrollados.
|
||||
|
||||
## Validadores y Listas de Nodos Únicos
|
||||
|
||||
#### ¿Qué servicio brindan los validadores de transacciones?
|
||||
|
||||
Todos los nodos garantizan que las transacciones cumplen los requisitos del protocolo y, por lo tanto, son "válidas". El servicio que proveen los validadores de manera única es agrupar administrativamente las transacciones en unidades ordenadas, acordando uno de esos órdenes específicamente para prevenir el doble gasto. <!-- STYLE_OVERRIDE: therefore -->
|
||||
|
||||
Ver [Consenso](../docs/concepts/consensus-protocol/index.md) para más información sobre el proceso de consenso.
|
||||
|
||||
|
||||
#### ¿Cuánto cuesta mantener un validador?
|
||||
|
||||
Mantener un validador no requiere de comisiones o XRP. Es comparable al gasto de ejecutar un servidor de correo electrónico en términos de uso de electricidad.
|
||||
|
||||
|
||||
#### ¿Qué son Las Listas de Nodos Únicos (UNLs)?
|
||||
|
||||
Las UNLs son las listas de validadores que un participante determinado cree que no conspirarán para defraudarle. Cada operador de servidor puede elegir su propia UNL, generalmente basándose en un cojunto determinado proporcionado por un publicador de confianza. (La lista predeterminada de un publicador a veces es llamada UNL predeterminada, o _dUNL_.) <!-- STYLE_OVERRIDE: will --> <!-- SPELLING_IGNORE: dUNL -->
|
||||
|
||||
|
||||
#### ¿Qué UNL debería escoger?
|
||||
|
||||
Dado que cualquiera puede montar un validador, la carga de elegir un conjunto confiable de validadores recae sobre los participantes. Actualmente, la XRP Ledger Foundation y Ripple publican listas predeterminadas recomendadas de valiadores de alta calidad, basadas en desesmpeño pasado, identidades comprobadas, y políticas de IT responsables. Sin embargo, cada participante de la red puede elegir qué validadores considera confiables y no necesita seguir a uno de los publicadores mencionados anteriormente.
|
||||
|
||||
|
||||
#### Si Ripple recomienda la adopción de su UNL, ¿Esto no crea un sistema centralizado?
|
||||
|
||||
No. Cada participante elige directa o indirectamente su UNL. Si Ripple dejase de operar o actuase de manera maliciosa, los participantes pueden cambiar sus UNLs para usar una lista de un publicador diferente.
|
||||
|
||||
|
||||
#### ¿Cuál es la estructura de incentivos para los validadores?
|
||||
|
||||
El principal incentivo para ejecutar un validador es preservar y proteger el funcionamiento estable y la evolución sensata de la red. Son los validadores quienes deciden la evolución del XRP Ledger, por lo que cualquier negocio que utilice o dependa del XRP Ledger tiene un incentivo inherente para garantizar la confiabilidad y estabilidad de la red. Los validadores también se ganan el respeto y la buena voluntad de la comunidad al contribuir de esta manera.
|
||||
|
||||
Si ejecutas un servidor XRP Ledger para participar en la red, el costo y el esfuerzo adicionales para ejecutar un validador son mínimos. Esto significa que no son necesarios incentivos adicionales, como las recompensas mineras en Bitcoin. Ripple evita pagar XRP como recompensa por operar un validador para que dichos incentivos no deformen el comportamiento de los validadores.
|
||||
|
||||
Para ver ejemplos de cómo los incentivos pueden distorsionar el comportamiento de validación, lee sobre [valor extraíble del minero (MEV en inglés)](https://arxiv.org/abs/1904.05234).
|
||||
|
||||
|
||||
#### ¿Pueden las instituciones financieras establecer validadores de transacciones para ayudarlas a cumplir estándares y requisitos institucionales específicos?
|
||||
|
||||
No, las instituciones no pueden configurar políticas de validación personalizadas para elegir permitir algunas transacciones y rechazar otras. Los validadores siguen el protocolo o no. Si el software no sigue las reglas del protocolo, no funciona. Por lo tanto, no se recomienda que las instituciones busquen implementaciones personalizadas sin experiencia interna.
|
||||
|
||||
|
||||
#### ¿Qué pasa si más del 20% de los nodos de la red no están de acuerdo con la mayoría? ¿Cómo se elige la versión final del ledger?
|
||||
|
||||
Normalmente, si hay una disputa sobre la validez de una transacción, esa transacción se pospone hasta que la mayoría pueda llegar a un acuerdo. Pero si más del 20% de la red no siguiera las mismas reglas de protocolo que la mayoría, la red se detendría temporalmente. Podría reanudarse cuando los participantes reconfiguren sus UNL en función de aquellos que quieran llegar a un consenso entre ellos. Se desea este retraso temporal en el procesamiento en lugar de duplicar el gasto.
|
||||
|
||||
En el proceso de determinar la versión autoritativa de un ledger, puede haber varias versiones internas temporales. Estas versiones internas ocurren naturalmente en sistemas distribuidos porque no todos los nodos reciben transacciones en el mismo orden. El comportamiento análogo en Bitcoin es cuando dos servidores ven cada uno una cadena más larga diferente porque dos bloques fueron extraídos aproximadamente al mismo tiempo.
|
||||
|
||||
Sin embargo, sólo puede haber una última versión del ledger _validated_ en un momento dado; otras versiones son irrelevantes e inofensivas.
|
||||
|
||||
Para obtener más información sobre cómo se comporta el mecanismo de consenso del XRP Ledger en situaciones adversas, consulta [Protecciones de consenso contra ataques y modos de fallo](../docs/concepts/consensus-protocol/consensus-protections.md).
|
||||
|
||||
|
||||
#### ¿El XRP Ledger tiene un proceso formal para añadir validadores?
|
||||
|
||||
No, un proceso formal para agregar validadores no es compatible con XRP Ledger, porque es un sistema sin autoridad central.
|
||||
|
||||
Los publicadores de UNL predeterminados individuales establecen sus propias políticas sobre cuándo agregar o eliminar validadores de sus listas de recomendaciones.
|
||||
|
||||
Para recomendaciones y mejores prácticas, consulta [Ejecutar `rippled` como validador](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).
|
||||
|
||||
|
||||
#### Si la dUNL tiene lmayor influencia en la red, ¿quiere decir que XRPL es centralizado?
|
||||
Los validadores pueden optar por no utilizar la dUNL o cualquier UNL ampliamente utilizada. Cualquiera puede crear una nueva UNL en cualquier momento.
|
||||
|
||||
Puede haber varias UNL en uso en la misma red. Cada operador puede personalizar la UNL de su propio servidor o elegir seguir una lista recomendada diferente. Todos estos servidores todavía pueden ejecutar la misma cadena y llegar a un consenso entre sí.
|
||||
|
||||
Sin embargo, si tu UNL no coincide lo suficiente con las UNL utilizadas por otros, existe el riesgo de que su servidor se separe (fork) del resto de la red. Siempre que tu UNL tenga > 90 % de superposición con la utilizada por las personas con las que transaccionas, estás completamente a salvo de bifurcarte. Si tiene menos superposición, es posible que aún puedas seguir la misma cadena, pero las posibilidades de bifurcarte aumentan con una menor superposición, peor conectividad de red y la presencia de validadores maliciosos o poco confiables en tu UNL.
|
||||
|
||||
|
||||
## Papel de XRP
|
||||
|
||||
|
||||
#### ¿Cuál es el proposito de XRP?
|
||||
|
||||
XRP se creó como el activo nativo de XRP Ledger para potenciar una nueva generación de pagos digitales: más rápidos, más ecológicos y más baratos que cualquier activo digital anterior. También sirve para proteger el ledger del spam y para [conectar divisas](../docs/concepts/tokens/decentralized-exchange/autobridging.md) en el exchange descentralizado del XRP Ledger, cuando hacerlo es beneficioso para los usuarios. Con el tiempo, la comunidad XRP Ledger ha sido pionera en nuevos [casos de uso](/about/uses) para XRP, al igual que el propio XRP Ledger.
|
||||
|
||||
|
||||
#### ¿Cómo responde el XRP Ledger al flood de transaciones?
|
||||
|
||||
El XRP Ledger está diseñado para establecer el [coste de transacción](../docs/concepts/transactions/transaction-cost.md) dinámicamente en función de la demanda como una medida antispam. El impacto de cualquier posible manipulación de XRP es minimizado a medida que la red crece, crece la capitalización y crece el volumen de transacciones.
|
||||
|
||||
|
||||
#### ¿Qué ocurre con el lavado de dinero y la actividad económica sospechosa?
|
||||
|
||||
<!-- STYLE_OVERRIDE: regarding -->
|
||||
|
||||
La red XRP Ledger es una red abierta y todas las transacciones son públicamente visibles.
|
||||
|
||||
Ripple se compromete a monitorear e informar cualquier indicador AML en la red XRP Ledger, así como a informar actividades sospechosas a FinCEN, según corresponda.
|
||||
|
||||
[XRP Forensics / xrplorer](https://xrplorer.com/) mantiene una lista de asesoramiento para rastrear y minimizar el lavado de dinero, las estafas, el fraude y el uso ilícito del XRP Ledger. Los exchanges y otros proveedores de servicios pueden utilizar este servicio para prevenir y reaccionar ante delitos financieros.
|
||||
|
||||
|
||||
## Consideraciones de seguridad
|
||||
|
||||
|
||||
#### ¿Cuál es el proceso para revisar las contribuciones de código de terceros?
|
||||
|
||||
El proceso de contribución de código comienza cuando un desarrollador abre una [pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) a un repositorio de código fuente como el [repositorio `rippled`](https://github.com/xrplf/rippled/), que contiene la implementación de referencia de Ripple del núcleo del servidor y del protocolo de XRP Ledger.
|
||||
|
||||
Este pull request activa pruebas unitarias y de integración automatizadas, así como revisiones de código por parte de varios desarrolladores que, por lo general, tienen experiencia significativa en el área de código a la que afecta al pull request.
|
||||
|
||||
Una vez que el pull request pasa las pruebas automatizadas y recibe la aprobación de los revisores, un [mantenedor del repositorio](https://opensource.guide/best-practices/) confiable puede prepararlo para su inclusión en la próxima versión beta.
|
||||
|
||||
|
||||
#### ¿Ripple posee o controla el XRP Ledger o la red XRP Ledger?
|
||||
|
||||
No, Ripple no posee ni controla el XRP Ledger o la red XRP Ledger.
|
||||
|
||||
Ripple contribuye a una implementación de referencia del nucleo del servidor de XRP Ledger ([`rippled`](https://github.com/xrplf/rippled)) y emplea un equipo de ingenieros que contribuyen al código base de código abierto. Ripple publica periodicamente paquetes binarios precompilados. Cualquiera puede [descargar y compilar el software desde la fuente](../docs/infrastructure/installation/index.md).
|
||||
|
||||
Varias entidades publican listas de validadores recomndadados (UNLs). Desde julio de 2023, Ripple mantiene solo uno de los 35 validadores que están en la UNL por defecto.
|
||||
|
||||
|
||||
#### ¿El XRP Ledger distingue entre el código base para la validación y el del software del usuario?
|
||||
|
||||
Sí. Hay varias [librerías de cliente para XRP Ledger](../docs/references/client-libraries.md) que están destinadas a desarrolladores de software de usuario. Estas librerias tienen distintos códigos base y repositorios del [núcleo del servidor XRP Ledger](../docs/concepts/networks-and-servers/index.md) que alimenta la red y valida las transacciones.
|
||||
126
@i18n/es-ES/about/privacy-policy.md
Normal file
126
@i18n/es-ES/about/privacy-policy.md
Normal file
@@ -0,0 +1,126 @@
|
||||
---
|
||||
seo:
|
||||
title: Política de privacidad
|
||||
description: Esta política describe cómo MTU XRP Ledger Trust respeta tu privacidad y detalla la recopilación, uso, y divulgación de los datos involucrados en el uso de este servicio.
|
||||
---
|
||||
# Política de privacidad de XRPL.org
|
||||
|
||||
Última actualización: 20 de enero, 2023
|
||||
|
||||
MTU XRP Ledger Trust (“MTU XRP Ledger Trust”, "Nosotros"", "Nuestro") respeta la necesidad de privacidad de los usuarios, y esta Política de Privacidad describe la recopilación, uso y divulgación de tu información cuando usas este servicio.
|
||||
|
||||
## Definiciones
|
||||
|
||||
Para los fines de esta Política de Privacidad:
|
||||
|
||||
* _Compañía_ - (referida como "MTU XRP Ledger Trust", "Nosotros", "Nuestro" en esta política) se refiere a XRPL.org
|
||||
* _Cookies_ - son pequeños ficheros que se colocan en tu ordenador, dispositivo móvil o cualquier otro dispositivo por un sitio web, conteniendo detalles de tu historial de navegación en ese sitio web entre sus muchos usos.
|
||||
* _Dispositivo_ - significa cualquier dispositivo que puede acceder al servicio, como un ordenador, un teléfono móvil o una tablet digital.
|
||||
* _Datos personales_ - es cualquier información que se relacione con un usuario identificado o identificable.
|
||||
* _Servicio_ - se refiere a este sitio web XRPL.org.
|
||||
* _Proveedor de servicios_ - significa cualquier persona normal o jurídica que procesa los datos en nombre de MTU XRP Ledger Trust. Se refiere a tercaras compañías o individuos contratados por MTU XRP Ledger Trust para facilitar el Servicio, para proveer el Servicio en nombre de MTU XRP Ledger Trust, para realizar servicios relacionados con el Servicio o para asistir a MTU XRP Ledger Trust analizando como el Servicio es utilizado.
|
||||
* _Datos de Uso_ - se refiere a datos recopilados automáticamente, generados por el uso del Servicio o la infraestructura del Servicio en sí (por ejemplo, la duración de una página visitada).
|
||||
* _Tú_ - significa el individuo que accede o usa el Servicio, o MTU XRP Ledger Trust, u otra entidad legal en nombre de la cual dicho individuo accede al Servicio, según corresponda.
|
||||
|
||||
## Recopilación y uso de tus datos
|
||||
|
||||
### Tipos de datos recopilados
|
||||
|
||||
**Datos de Uso** se recopilan automáticamente al utilizar este Servicio. Los Datos de Uso pueden incluir información como la dirección de Protocolo de Internet de Tu Dispositivo (por ejemplo, dirección IP), tipo de navegador, versión del navegador, las páginas de nuestro Servicio que Tu visitas, la hora y fecha de Tu visita, el tiempo que pasa en esas páginas, identificadores de dispositivos únicos y otros datos de diagnóstico.
|
||||
|
||||
Cuando accedes al Servicio a través de un dispositivo móvil, Nosotros podemos recopilar cierta información automáticamente, incluido, entre otros, el tipo de dispositivo móvil que Tu utilizas, TU ID único de dispositivo móvil, la dirección IP de Tu dispositivo móvil, Tu sistema operativo móvil, el tipo de navegador de Internet móvil que Tu utilizas, identificadores de dispositivos únicos y otros datos de diagnóstico.
|
||||
|
||||
Nosotros también podemos recopilar información que Tu navegador envía cada vez que visita Nuestro Servicio o cuando accedes al Servicio a través de un dispositivo móvil.
|
||||
|
||||
## Tecnologías de seguimiento y cookies
|
||||
|
||||
Nosotros utilizamos Cookies y tecnologías de seguimiento similares para rastrear la actividad en Nuestro Servicio y almacenar cierta información. Las tecnologías de seguimiento utilizadas son beacons, tags y scripts para recopilar y rastrear información y para mejorar y analizar Nuestro Servicio. Las tecnologías que utilizamos pueden incluir:
|
||||
|
||||
* _Cookies o Cookies del Navegador_ - Una cookie es un pequeño archivo colocado en Tu Dispositivo. Puede instruir a Tu navegador para que rechace todas las Cookies o para que te indique cuándo se envía una Cookie. Sin embargo, si Tu no aceptas Cookies, es posible que no puedas utilizar algunas partes de nuestro Servicio. A menos que hayas ajustado Tu configuración del navegador para que rechace Cookies, nuestro Servicio puede utilizar Cookies.
|
||||
* _Cookies Flash_ - Ciertas funciones de nuestro Servicio pueden utilizar objetos almacenados localmente (o Cookies Flash) para recopilar y almacenar información sobre Tus preferencias o Tu actividad en nuestro Servicio. Las Cookies Flash no son administradas por la misma configuración del navegador que se utiliza para las Cookies del Navegador.
|
||||
* _Web Beacons_ - Ciertas secciones de nuestro Servicio pueden contener pequeños archivos electrónicos conocidos como web beacons (también denominadas clear gifs, pixel tags y gifs de píxeles únicos) que permiten a la Compañía, por ejemplo, contar usuarios que han visitado esas páginas o abierto un correo electrónico y para otras estadísticas relacionadas con el sitio web (por ejemplo, registrar la popularidad de una cierta sección y verificar la integridad del sistema y del servidor).
|
||||
|
||||
Las Cookies pueden ser "Persistentes" o de "Sesión". Las Cookies Persistentes permanecen en Tu computadora personal o dispositivo móvil cuando te desconectas, mientras que las Cookies de Sesión se eliminan tan pronto como cierras Tu navegador web.
|
||||
|
||||
## Use of Your Usage Data
|
||||
|
||||
La Compañía puede utilizar Datos de Uso para los siguientes propósitos:
|
||||
|
||||
**Proporcionar o mantener nuestro Servicio**, incluyendo el monitoreo del uso de nuestro Servicio.
|
||||
**Para gestionar Tus peticiones:** Para atender y gestionar Tus solicitudes por Nosotros.
|
||||
|
||||
**Para otros propositos:** Podemos utilizar Tus Datos de Uso para otros propósitos, tales como el análisis de datos, identificar tendencias de uso, determinar la eficacia de nuestras campañas publicitarias y para evaluar y mejorar nuestro Servicio y Tu experiencia.
|
||||
|
||||
Puede que compartamos Tus Datos de Uso en las siguientes situaciones:
|
||||
|
||||
**Con Proveedores de servicios:** Podemos compartir Tus Datos de Uso con Proveedores de servicios para monitorear y analizar el uso de Nuestro Servicio.
|
||||
|
||||
**Con socios comerciales:** Podemos compartir Tus Datos de Uso con Nuestros socios comerciales que proporcionan contenido en este sitio web.
|
||||
|
||||
**Con Tu consentimiento:** Podemos divulgar Tus Datos de Uso para cualquier otro propósito con Tu consentimiento.
|
||||
|
||||
## Retención de Tus Datos de Uso
|
||||
|
||||
La Compañía retendrá Tus Datos de Uso solo durante el tiempo que sea necesario para los fines establecidos en esta Política de Privacidad. Conservaremos y utilizaremos Tus Datos de Uso en la medida necesaria para cumplir con nuestras obligaciones legales (por ejemplo, si estamos obligados a conservar tus datos para cumplir con las leyes aplicables, fortalecer la seguridad o mejorar la funcionalidad de Nuestro Servicio, resolver disputas y hacer cumplir nuestros acuerdos y políticas legales.
|
||||
|
||||
## Transferencia de Tus Datos de Uso
|
||||
|
||||
Tus Datos de Uso son procesados en las oficinas operativas de la Compañía y en cualquier otro lugar donde se encuentren las partes involucradas del procesamiento. Esto significa que esta información puede ser transferida a — y mantenida en — computadoras ubicadas fuera de Tu estado, provincia, país u otra jurisdicción gubernamental donde las leyes de protección de datos pueden diferir de las de Tu jurisdicción.
|
||||
|
||||
Tu consentimiento a esta Política de Privacidad seguido de Tu envío de dicha información representa Tu acuerdo con esa transferencia.
|
||||
|
||||
## Divulgación de Tus Datos de Uso
|
||||
|
||||
## Aplicación de la ley
|
||||
|
||||
Bajo ciertas circunstancias, La Compañía puede estar obligada a divulgar Tus Datos de Uso si es requerido por la ley o en respuesta a peticiones válidas de autoridades públicas (por ejemplo, un tribunal o un agencia gubernamental).
|
||||
|
||||
## Otros requisitos legales
|
||||
|
||||
La Compañía puede divulgar Tus Datos de Uso en creencia de buena fe de que dicha accion es necesaria para:
|
||||
|
||||
* Cumplir con una obligación legal
|
||||
* Proteger y defender los derechos y propiedades de La Compañía
|
||||
* Prevenir o investigar posibles irregularidades en relación con el Servicio
|
||||
* Proteger la seguridad personal de los Usuarios del Servicio o del público
|
||||
* Protegerse contra la responsabilidad legal
|
||||
|
||||
## Seguridad de Tus Datos Personales
|
||||
|
||||
La seguridad de Tus Datos es importante para Nosotros, pero recuerda que ningún método de transmisión por Internet o método de almacenamiento electrónico es 100% seguro. Si bien nos esforzamos por utilizar medios comercialmente aceptables para proteger Tus Datos, no podemos garantizar su seguridad absoluta.
|
||||
|
||||
## Privacidad de los niños
|
||||
|
||||
Nuestro Servicio no se dirige a nadie menor de 13 años. No recopilamos de manera consciente información de identificación personal de nadie menor de 13 años. Si Tu eres padre/madre o tutor y sabes que Tu hijo nos ha proporcionado Datos Personales, por favor, contáctanos. Si nos damos cuenta de que hemos recopilado Datos Personales de alguien menor de 13 años sin verificación del consentimiento de los padres, tomamos medidas para eliminar esa información de Nuestros servidores.
|
||||
|
||||
Si necesitamos basarnos en el consentimiento como base legal para procesar Tu información y Tu país requiere consentimiento de un padre, podemos requerir el consentimiento de Tus padres antes de recopilar y usar esa información.
|
||||
|
||||
## Enlaces a otros sitios web
|
||||
|
||||
Nuestro Servicio puede contener enlaces a otros sitios web que no son operados por Nosotros. Si haces clic en un enlace de un tercero, serás dirigido a ese sitio web de terceros. Te recomendamos encarecidamente que revises la Política de Privacidad de cada sitio que visites.
|
||||
|
||||
No tenemos control sobre, y no asumimos responsabilidad por el contenido, políticas de privacidad o prácticas de sitios o servicios de terceros.
|
||||
|
||||
## Cambios en esta Política de Privacidad
|
||||
|
||||
Podemos actualizar Nuestra Política de Privacidad de vez en cuando. Te notificaremos cualquier cambio publicando la nueva Política de Privacidad en esta página. Te proporcionaremos un aviso destacado en Nuestro Servicio, antes de que el cambio entre en vigor y actualizaremos la fecha de "Última actualización" en la parte superior de esta Política de Privacidad.
|
||||
|
||||
Te recomendamos que revises esta Política de Privacidad periódicamente para ver si hay cambios. Los cambios a esta Política de Privacidad son efectivos cuando se publican en esta página.
|
||||
|
||||
## Contáctanos
|
||||
|
||||
Si tienes alguna pregunta sobre nuestra Política de Privacidad, puedes contactarnos:
|
||||
|
||||
MTU XRP Ledger Trust
|
||||
|
||||
**Oficina en Regd**
|
||||
15, Ringtee
|
||||
Kuressaare
|
||||
Estonia 93815
|
||||
|
||||
**Oficina en Tallinn**
|
||||
802, Lõõtsa tn 5
|
||||
Tallinn
|
||||
Estonia 11415
|
||||
|
||||
**Por correo electrónico:** info@xrplf.org
|
||||
31
@i18n/es-ES/community/report-a-scam.md
Normal file
31
@i18n/es-ES/community/report-a-scam.md
Normal file
@@ -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).
|
||||
84
@i18n/es-ES/docs/concepts/accounts/account-types.md
Normal file
84
@i18n/es-ES/docs/concepts/accounts/account-types.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
html: account-types.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Los negocios que envían transacciones en el XRP Ledger automáticamente, deben configurar direcciones separadas para diferentes propósitos para minimizar el riesgo.
|
||||
labels:
|
||||
- Tokens
|
||||
- Seguridad
|
||||
---
|
||||
# Tipos de cuenta
|
||||
|
||||
{% partial file="/docs/_snippets/issuing-and-operational-addresses-intro.md" /%}
|
||||
|
||||
|
||||
## Ciclo de vida de los fondos
|
||||
|
||||
Cuando un emisor de tokens sigue esta separacion de roles, los fondos tienden a fluir en direcciones específicas, como se muetra en el siguiente diagrama:
|
||||
|
||||
[{% inline-svg file="/docs/img/issued-currency-funds-flow.svg" /%}](/docs/img/issued-currency-funds-flow.svg "Diagrama: Los fondos fluyen desde la dirección emisora hasta las direcciones de reserva, a direcciones operacionales, hacia las direcciones de clientes y socios, y finalmente de regreso a la dirección emisora.")
|
||||
|
||||
La dirección emisora crea tokens enviando pagos a direcciones de reserva. Esos tokens tienen un valor negativo desde la perspectiva de la dirección emisora, ya que (a menudo) representan obligaciones. Los mismos tokens tienen valor positivo desde la otras perspectivas, incluyendo desde la perspectiva de las direcciones de reserva.
|
||||
|
||||
Las direcciones de reserva, que son operadas por personas reales, envían esos tokens a direcciones operacionales. Este paso permite que la dirección emisora sea utilizada lo menos posible después de este punto, mientras tienen al menos algunos tokens disponibles en espera.
|
||||
|
||||
Las direcciones operacionales, las cuales son operadas por sistemas automatizados, envían pagos a otras contrapartes, como proveedores de liquidez, socios y otros clientes. Esas contrapartes pueden enviar fondos libremente entre ellas varias veces.
|
||||
|
||||
Como siempre, los pagos con tokens deben moverse a través de líneas de confianza (trust lines) del emisor.
|
||||
|
||||
Eventualmente, alguien envía tokens de vuelta al emisor. Esto destruye esos tokens, reduciendo las obligaciones del emisor con el XRP Ledger. Si el token es una stablecoin, esto es el primer paso para canjear los tokens por los activos correspondientes fuera del ledger.
|
||||
|
||||
|
||||
## Dirección emisora
|
||||
|
||||
La dirección emisora es como una caja fuerte. Los socios, clientes y direcciones operacionales crean, líneas de confianza (trust lines) a la dirección emisora, pero esta dirección envía la menor cantidad de transacciones posibles. Periodícamente, un operador humano crea y firma una transacción desde la dirección emisora para recargar los balances de una dirección operacional o de reserva. Idealmente, la clave secreta utilizada para firmar esas transacciones nunca debería ser accesible desde ningun equipo conectado a Internet.
|
||||
|
||||
A diferencia de una caja fuerte, la dirección emisora puede recibir pagos directamente de clientes o socios. Como todas las transacciones en el XRP Ledger son públicas, los sistemas automatizados pueden observar los pagos a la dirección emisora sin necseisdad de una clave secreta.
|
||||
|
||||
### Dirección emisora comprometida
|
||||
|
||||
Si un actor malicioso descubre la clave secreta de la dirección emisora de una institución, ese actor puede crear nuevos tokens y enviarlos a usuarios o intercambiarlos en el exchange descentralizado. Esto puede hacer hacer a un emisor de stablecoin insolvente. Puede resultar dificil para la institución financiera distinguir los tokens obtenidos legítimanente y canjearlos de manera justa. Si una institución pierde el control de la dirección emisora, la institución debe crear una nueva dirección emisora, y todos los usuarios que tenían una trust line a la dirección emisora antigua, deben crear un nueva trust line a la nueva dirección.
|
||||
|
||||
### Múltiples direcciones de emisión
|
||||
|
||||
Una institución financiera puede emitir más de un token en el XRP Ledger desde una única dirección de emisión. Sin embargo, hay algunas configuraciones que se aplican por igual a todos los tokens (fungibles) emitidos desde una dirección, incluido el porcentaje de [comisiones de transferencia](../tokens/transfer-fees.md) y el estado [congelación global](../tokens/fungible-tokens/freezes.md). Si la intitución financiera quiere la flexibilidad de manejar las configuraciones de distinta manera para cada token, la institución debe tener múltiples direcciones emisoras.
|
||||
|
||||
|
||||
## Direcciones operacionales
|
||||
|
||||
Una dirección operacional es como una caja registradora. Realiza pagos en nombre de la institución para transferir tokens a clientes y socios. Para firmar transacciones automáticamente, la clave secreta para una dirección operacional debe ser alacenada en un servidor que está conectado a Internet. (La clave secreta puede estar almacenada encriptada, pero el servidor debe desencriptarla para firmar las transacciones.) Clientes y socios no crean ni deben crear trust lines a direcciones operacionales.
|
||||
|
||||
Cada dirección operacional tiene un balance limitado de tokens y XRP. Cuando el balance de una dirección operacional disminuye, la institución financiera la recarga enviando un pago desde la dirección emisora o desde la dirección de reserva.
|
||||
|
||||
### Direciones operacionales comprometidas
|
||||
|
||||
Si un actor malicioso descubre la clave secreta detrás de una dirección operacional, la institución financiera sólo puede perder tanto como esa dirección operacional contiene. La institución puede cambiar a una nueva dirección operacional sin que los clientes y socios tengan que realizar ninguna acción.
|
||||
|
||||
|
||||
## Direcciones de reserva
|
||||
|
||||
Otro paso opcional que una institución puede equilibrar el riesgo y la convivencia es utilizada como "direcciones de reserva" como paso intermedio entre la dirección emisora y las direcciones operativas. La institución puede financiar direcciones XRP Ledger adicionales como direcciones de reserva, cuyas claves no están disponibles para los servidores siempre en línea, sino que confian a diferentes usuarios confiables.
|
||||
|
||||
Cuando una dirección operacional se está quedando sin fondos (ya sea tokens o XRP), un usuario confiable pueed utilizar su dirección de reserva para recargar el balance de una dirección operacional. Cuando una dirección de reserva se queda sin fondos, la institución puede usar la dirección emisora para enviar más fondos a la dirección de reserva en una sola transacción, y la dirección de reserva puede distribuir esos fondos entre sí si es necesario. Esto mejora la seguridad de la dirección emisora, permitíendole hacer menos transacciones, sin dejar demasiado dinero en un único sistema automatizado.
|
||||
|
||||
Como con las direcciones operacionales, una direccion de reserva debe tener una relación contable con la dirección emisora, y no con los clientes o socios. Todas las precauciones que aplican a las direcciones operacionales también aplican a las direcciones de reserva.
|
||||
|
||||
### Dirección de reserva comprometida
|
||||
|
||||
Si una dirección de reserva se ve comprometida, las consecuencias son similares a las de una dirección operacional. Un actor malintencionado puede robar cualquier saldo que posea la dirección de reserva, y la institución financiera puede cambiar a una nueva dirección de reserva sin que los clientes y socios realicen ninguna acción.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Cuentas](index.md)
|
||||
- [Claves criptográficas](cryptographic-keys.md)
|
||||
- **Tutoriales:**
|
||||
- [Asignar par de claves regulares](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
|
||||
- [Cambiar o eliminar par de claves regulares](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
|
||||
- **Referencias:**
|
||||
- [metodo account_info][]
|
||||
- [Transacción SetRegularKey][]
|
||||
- [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
96
@i18n/es-ES/docs/concepts/accounts/addresses.md
Normal file
96
@i18n/es-ES/docs/concepts/accounts/addresses.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
html: addresses.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Las direcciones identifican de manera única las cuentas del XRP Ledger, utilizando el formato base58.
|
||||
labels:
|
||||
- Cuentas
|
||||
---
|
||||
# Direcciones
|
||||
|
||||
{% partial file="/docs/_snippets/data_types/address.md" /%}
|
||||
|
||||
Cualquier dirección válida puede [convertirse en una cuenta en el XRP Ledger](index.md#creacion-de-cuentas) al recibir fondos. Puedes utilizar una cuenta que no ha recibido fondos para representar una [clave normal, regular key en inglés](cryptographic-keys.md) o ser miembro de una [lista de firmantes](multi-signing.md). Solo una cuenta que ha recibido fondos puede ser el remitente de una transacción.
|
||||
|
||||
Crear una dirección válida es una tarea estríctamente matemática que empieza con el par de claves. Puedes generar un par de claves y calcular su dirección completamente offline sin comunicarte con el XRP Ledger o con cualquier otra entidad. La conversión desde una clave pública a una dirección implica una función hash unidireccional, por lo que es posible confirmar que esa clave pública coincide con una dirección pero es imposible derivar la clave pública únicamente a partir de la dirección. (Esta es parte de la razón por la que las transacciones firmadas incluyen la clave pública _y_ la dirección del remitente.)
|
||||
|
||||
|
||||
## Direcciones especiales
|
||||
|
||||
Algunas direcciones tienen un significado especial, o usos históricos, en el XRP Ledger. En muchos casos, se tratan de direcciones "black hole" o agujero negro, lo que significa que la dirección no se deriva de una clave secreta conocida. Como es efectivamente imposible adivinar una clave secreta a partir de una sola dirección, cualquier XRP que posean direcciones black hole estarán perdidos para siempre.
|
||||
|
||||
|
||||
| Dirección | Nombre | Significado | ¿Black Hole? |
|
||||
|-------------------------------|--------|-------------|--------------|
|
||||
| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `0`. En comunicaciones peer-to-peer, `rippled` utiliza esta dirección como el emisor de XRP. | Sí |
|
||||
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | Una dirección que es la codificación en [base58][] en el XRP Ledger del valor `1`. En el ledger, las [entradas RippleState](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) utilizan esta dirección como marcador de posición para el emisor de un balance de una trust line. | Sí |
|
||||
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | La cuenta génesis | Cuando `rippled` inicia un nuevo ledger génesis desde el principio (por ejemplo, en modo solitario), esta cuenta contiene todo el XRP. Esta cuenta es generada con el valor semilla `masterpassphrase` el cual está [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
|
||||
| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | black hole de reserva de nombre de Ripple | En el pasado, Ripple pedía a los usuarios enviar XRP a esta cuenta para reservar nombres Ripple.| Sí |
|
||||
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | Dirección NaN | Versiones previas de [ripple-lib](https://github.com/XRPLF/xrpl.js) generaban esta dirección cuando se codificaba el valor [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) utilizan el formato de codificación [base58][] del XRP Ledger. | Sí |
|
||||
|
||||
|
||||
## Codificación de una dirección
|
||||
|
||||
**Consejo:** ¡Estos detalles técnicos son solo relevantse para personas que crean librerias de software de bajo nivel para la compatibilidad con el XRP Ledger!
|
||||
|
||||
[[Fuente]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Fuente")
|
||||
|
||||
Las direcciones XRP Ledger están codificadas utilizando [base58][] con el _diccionario_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Como el XRP Ledger codifica varios tipos de claves con base58, antepone los datos codificados con un-byte de "prefijo de tipo" (también conocido como "prefijo de versión") para distinguirlos. El prefijo de tipo hace que las direcciones normalmente comiencen con diferentes letras en formato base58.
|
||||
|
||||
El siguiente diagrama muestra la relación entre las claves y las direcciones:
|
||||
|
||||
[{% inline-svg file="/docs/img/address-encoding.svg" /%}](/docs/img/address-encoding.svg "Clave pública maestra + Prefijo Tipo → ID de cuenta + Checksum → Dirección")
|
||||
|
||||
La fórmula para calcular direcciones XRP Ledger desde una clave pública es la siguiente. Para ver el código de ejemplo completo, consulta [`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js). Para el proceso de derivar la clave pública desde una passphrase a un valor semilla, consulta [Derivación de clave](cryptographic-keys.md#key-derivation).
|
||||
|
||||
1. Importa los algoritmos necesarios: SHA-256, RIPEMD160, y base58. Configura el diccionario para base58.
|
||||
|
||||
```
|
||||
'use strict';
|
||||
const assert = require('assert');
|
||||
const crypto = require('crypto');
|
||||
const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
|
||||
const base58 = require('base-x')(R_B58_DICT);
|
||||
|
||||
assert(crypto.getHashes().includes('sha256'));
|
||||
assert(crypto.getHashes().includes('ripemd160'));
|
||||
```
|
||||
|
||||
2. Empieza con una clave pública 33-byte ECDSA secp256k1, o una clave pública 32-byte Ed25519. Para claves Ed25519, prefija la clave con el byte `0xED`.
|
||||
|
||||
```
|
||||
const pubkey_hex =
|
||||
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
|
||||
const pubkey = Buffer.from(pubkey_hex, 'hex');
|
||||
assert(pubkey.length == 33);
|
||||
```
|
||||
|
||||
3. Calcula el hash [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) del hash SHA-256 de la clave pùblica. Este valor es el ID de cuenta o "Account ID".
|
||||
|
||||
```
|
||||
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
|
||||
const pubkey_outer_hash = crypto.createHash('ripemd160');
|
||||
pubkey_outer_hash.update(pubkey_inner_hash.digest());
|
||||
const account_id = pubkey_outer_hash.digest();
|
||||
```
|
||||
|
||||
4. Calcula el hash SHA-256 hash del hash SHA-256 del Account ID; toma los 4 primeros bytes. Este valor es el "checksum".
|
||||
|
||||
```
|
||||
const address_type_prefix = Buffer.from([0x00]);
|
||||
const payload = Buffer.concat([address_type_prefix, account_id]);
|
||||
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
|
||||
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
|
||||
const checksum = chksum_hash2.slice(0,4);
|
||||
```
|
||||
|
||||
5. Concatena el payload y el checksum. Calcula el valor base58 del buffer concatenado. El resultado es la dirección.
|
||||
|
||||
```
|
||||
const dataToEncode = Buffer.concat([payload, checksum]);
|
||||
const address = base58.encode(dataToEncode);
|
||||
console.log(address);
|
||||
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
|
||||
```
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
259
@i18n/es-ES/docs/concepts/accounts/cryptographic-keys.md
Normal file
259
@i18n/es-ES/docs/concepts/accounts/cryptographic-keys.md
Normal file
@@ -0,0 +1,259 @@
|
||||
---
|
||||
html: cryptographic-keys.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Utiliza las claves criptográficas para aprobar transacciones para que el XRP Ledger pueda ejecutarlas.
|
||||
labels:
|
||||
- Smart Contracts
|
||||
- Seguridad
|
||||
---
|
||||
# Claves criptográficas
|
||||
|
||||
En el XRP Ledger, una firma digital _autoriza_ a una [transacción](../transactions/index.md) a hacer un grupo específico de acciones. Solo las transacciones firmadas pueden ser enviadas a la red y ser incluidas en un ledger validado.
|
||||
|
||||
Para realizar una firma digital, utilizas un par de claves criptográficas asociadas con la cuenta de envío de la transacción. Un par de claves se puede generar utilizando cualquiera de los [algoritmos de firma criptorgráfica](#algoritmos-de-firma) soportados por el XRP Ledger. Un par de claves puede ser utilizado como [par de claves maestras](#par-de-claves-maestras), [par de claves normales](#par-de-claves-normales) o un miembro de una [lista de firmantes](multi-signing.md), sin importar qué algoritmo se ha utilizado para generarlo.
|
||||
|
||||
**Atención:** Es importante mantener una seguridad adecuada sobre tus claves criptográficas. Las firmas digitales son la única forma de autorizar transacciones en el XRP Ledger, y no hay administrador privilegiado que pueda deshacer o revertir cualquier transacción tras haber sido aplicadas. Si alguien más conoce la semilla o la clave privada de tu cuenta del XRP Ledger, esa persona puede crear firmas digitales para autorizar cualquier transacción al igual que tú.
|
||||
|
||||
## Generación de claves
|
||||
|
||||
Muchas [librerías de cliente](../../references/client-libraries.md) y aplicaciones pueden generar un par de claves adecuadas para usar con el XRP Ledger. Sin embargo, solo deberías utilizar los pares de claves que fueron generados en dispositivos y software en los que confías. Las aplicaciones comprometidas pueden exponer tu secreto a usuarios maliciosos que pueden enviar transacciones desde tu cuenta luego.
|
||||
|
||||
|
||||
## Componentes de clave
|
||||
|
||||
Un par de claves criptográficas es una **clave privada** y una **clave pública** que están conectadas matemáticamente a través de un proceso de derivación de claves. Cada clave es un número; la clave privada debería elegirse usando una fuente de aleatoriedad fuerte. El [algoritmo de firma criptográfica](#algoritmos-de-firma) define el proceso de derivación de claves y establece restricciones en los números que pueden ser claves criptográficas.
|
||||
|
||||
Al tratar con el XRP Ledger, también puedes utilizar algunos valores relacionados como passphrase, semilla, ID de cuenta, y dirección.
|
||||
|
||||
[{% inline-svg file="/docs/img/cryptographic-keys.svg" /%}](/docs/img/cryptographic-keys.svg "Diagrama: Passphrase → Semilla → Clave privada → Clave pública → ID de cuenta ←→ Dirección")
|
||||
_Figura: Una vista simplificada de la relación entre los valores de clave criptográfica._
|
||||
|
||||
La passphrase, semilla, y la clave privada son **secretos**: si conoces alguno de estos valores para una cuenta, puedes generar firmas válidas y tienes el control total sobre la cuenta. Si tienes una cuenta, se **muy cuidadoso** con la información secreta de tu cuenta. Si no tienes estos secretos, no puedes usar tu cuenta. Si alguien más tiene acceso a ellos, puede tener el control de tu cuenta.
|
||||
|
||||
La clave pública, el ID de cuenta, y dirección son información pública. Puede haber situaciones en las que puedes conservar la clave pública para ti mismo, pero en algún momento necesites publicarla como parte de una transacción para que el XRP Ledger pueda verificar la firma y el proceso de la transacción.
|
||||
|
||||
Para más detalles técnicos y como la derivación de clave funciona, ver [Derivación de claves](#derivación-de-claves).
|
||||
|
||||
### Passphrase
|
||||
|
||||
Puedes, opcionalmente, usar una passphrase u algún otro valor de entrada como forma de elegir una semilla o una clave privada. Esto es menos seguro que elegir la semilla o la clave privada desde la aleatoriedad, pero hay algunos casos excepcionales dónde quieras hacer esto. (Por ejemplo, en 2018 "XRPuzzler" regaló XRP a la primera persona [en resolver un puzzle](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/); él utilizó la solución del puzzle como la passphrase para la cuenta que tenía el premio en XRP.) <!-- SPELLING_IGNORE: xrpuzzler -->
|
||||
|
||||
La passphrase es información secreta, por lo que debes protegerla con mucho cuidado. Cualquiera que conozca la passphrase de la dirección tiene control total efectivo sobre la cuenta.
|
||||
|
||||
### Semilla
|
||||
|
||||
Un valor _semilla_ es un valor compacto que se utiliza para [derivar](#derivación-de-claves) las claves privada y pública actual de una cuenta. En la respuesta de un [método wallet_propose][], las `master_key`, `master_seed`, y `master_seed_hex` todas representan el mismo valor semilla, en varios formatos. Cualquiera de esos formatos puede ser utilizado para firmar transacciones. A pesar de tener el prefijo `master_`, las claves que esta semilla representa no necesariamente representan las claves maestras de una cuenta; puedes usar un par de claves como una clave normal o un miembro de una lista de firmantes.
|
||||
|
||||
El valor semilla es una información secreta, por lo que debes que protegerla con mucho cuidado. Cualquiera que conozca el valor semilla de una dirección tiene control total sobre la dirección.
|
||||
|
||||
### Clave privada
|
||||
|
||||
La _clave privada_ es un valor utilizado para crear una firma digital. La mayoría de software XRP Ledger no muestra explicitamente la clave privada, y [deriva la clave privada](#derivación-de-claves) desde el valor semilla cuando es necesario. Es técnicamente posible guardar la clave privada en vez de la semilla para usarla con el fin de firmar transacciones directamente, pero no es algo común.
|
||||
|
||||
Como la semilla, la clave privada es información secreta, por lo que debes protegerla con mucho cuidado. Cualquiera que conozca la clave privada de la dirección tiene control total sobre la dirección.
|
||||
|
||||
### Clave pública
|
||||
|
||||
La _clave pública_ es un valor utilizado para verificar la autenticidad de una firma digital. La clave pública se deriva de una clave privada como parte de la derivación de clave. En la respuesta de un [método wallet_propose][], ambas, la `public_key` y `public_key_hex` representan el mismo valor de clave pública.
|
||||
|
||||
Las transacciones en el XRP Ledger deben incluir las claves públicas para que la red pueda verificar las firmas de las transacciones. La clave pública no se puede utilizar para crear firmas válidas, así que es seguro compartirla públicamente.
|
||||
|
||||
|
||||
### ID de cuenta y dirección
|
||||
|
||||
El **ID de cuenta** es el identificador principal para una [cuenta](index.md) o para un par de claves. Se deriva de la clave pública. En el protocolo XRP Ledger, el ID de cuenta es un dato binario de 20 bytes. La mayoría de las APIs XRP Ledger representan la Account ID como una dirección, en uno de dos formatos:
|
||||
|
||||
- Una "dirección clásica" escribe una ID de cuenta en [base58][] con un checksum. En una respuesta del [método wallet_propose][], este es el valor `account_id`.
|
||||
- Una "dirección-X" combina una ID de cuenta _y_ un [Tag de destino](../transactions/source-and-destination-tags.md) y escribe el valor combinado en [base58][] con un checksum.
|
||||
|
||||
El checksum en ambos formatos está ahi para que los resultados con pequeños cambios resulte en una dirección inválida, en lugar de cambiarla para que haga referencia a una cuenta diferente, pero aún potencialmente válida. De esta forma, si cometes un error tipográfico u ocurre un error de tranmisión, no enviarás dinero al lugar equivocado.
|
||||
|
||||
Es importante saber que no todos los IDs de cuenta (o direcciones) se refieren a cuentas en el ledger. Derivar claves y direcciones es una operación puramente matemática. Para que una cuenta tenga un registro en el XRP Ledger, es necesario [recibir un pago en XRP](index.md#creating-accounts) que cumpla su [requisito de reservas](reserves.md). Una cuenta no puede enviar ninguna transacción hasta que se haya recibido fondos.
|
||||
|
||||
Incluso si una ID de cuenta o dirección no se refiere a una cuenta con fodos, _puedes_ usar ese ID de cuenta o la dirección para representar un [par de claves](#par-de-claves-normales) o un [miembro de una lista de firmantes](multi-signing.md).
|
||||
|
||||
### Tipo de clave
|
||||
|
||||
El XRP Ledger soporta más de un [algoritmo de firma criptográfica](#algoritmos-de-firma). Cualquier par de claves determinado es únicamente válida para un algoritmo de firma criptográfica específico. Algunas claves privadas pueden técnicamente ser claves válidas para más de un algoritmo, pero esas claves privadas tendrían distintas claves públicas para cada algoritmo, y no deberías reutilizar las claves privadas.
|
||||
|
||||
El campo `key_type` en el [método wallet_propose][] se refiere al algoritmo de firma criptográfica que se utilizará.
|
||||
|
||||
|
||||
## Par de claves maestras
|
||||
|
||||
El par de claves maestras consiste en una clave privada y una clave publica. La dirección de una cuenta es derivada del par de claves maestras, por lo que están intrinsecamente relacionadas. No puedes cambiar o eliminar el par de claves maestras, pero puedes desactivarlo.
|
||||
|
||||
El [metodo wallet_propose][] es una forma de generar el par de claves maestras. La respuesta de este método muestra la semilla de la cuenta, dirección, y la clave pública maestra juntos. Para ver otros métodos para configurar pares de claves maestras, consultar [Firma segura](../transactions/secure-signing.md).
|
||||
|
||||
**Atención:** Si un actor malicioso conoce tu clave privada maestra (o semilla), tendrá control completo sobre tu cuenta, a no ser que tu par de claves maestras se inhabilite. Puedes tomar todo tu dinero de la cuenta posee y causar un daño irreparable. ¡Trata tus valores secretos con cuidado!
|
||||
|
||||
Dado que cambiar el par de claves maestras es imposible, debes cuidarlo en proporción al valor de lo que posea. Una buena práctica es [guardar tu par de claves maestras offline](../../tutorials/how-tos/manage-account-settings/offline-account-setup.md) y configurar un par de claves normales para firmar transacciones en tu cuenta. Al mantener el par de claves maestras activadas pero offline, puedes estar razonablemente seguro de que nadie puede acceder a él a través de Internet, pero aun así deberías encontrarlo en caso de una emergencia.
|
||||
|
||||
Mantener tu par de claves maestras offline significa no colocar tu información secreta (passphrase, semilla, or clave privada) en cualquier sitio en que los actores maliciosos puedan tener acceso a él. En general, esto quiere decir que no está al alcance de un programa inofrmático que interactúe con Internet. Por ejemplo, puedes guardarlo en un equipo que no se conecta nunca a Internet, en un trozo de papel guardado en una caja fuerte, o tenerla completamente memorizada. (Memorizarla tiene algunos puntos inconvenientes, incluido ser imposible pasar la clave una vez muerto.)
|
||||
|
||||
|
||||
|
||||
### Permisos especiales
|
||||
|
||||
**Solo** el par de claves maestras pueden autorizar transacciones para hacer ciertas cosas:
|
||||
|
||||
- Enviar la primera transacción de una cuenta, porque las cuentas no se pueden inicializar de otra manera que [autorizando transacciones](../transactions/index.md#authorizing-transactions).
|
||||
|
||||
- Deshabilitar el par de claves maestras.
|
||||
|
||||
- Renunciar permanentemente a la posibilidad de [congelar](../tokens/fungible-tokens/freezes.md#no-freeze).
|
||||
|
||||
- Enviar una [transacción de reestablecimiento de clave](../transactions/transaction-cost.md#key-reset-transaction) especial con una transacción de 0 XRP de coste.
|
||||
|
||||
Una clave normal o [multi-firma](multi-signing.md) puede hacer cualquier otra cosa igual que el par de claves maestras. En particular, una vez has deshabilitado el par de claves maestras, puedes volver a habilitarlo utilizando un par de claves normales o multi firma. También puedes [eliminar una cuenta](deleting-accounts.md) si cumple con los requisitos para su eliminación.
|
||||
|
||||
|
||||
## Par de claves normales
|
||||
|
||||
Una cuenta XRP Ledger puede autorizar un par de claves secundario, conocido como _par de claves normales_. Tras hacerlo, puedes utilizar cualquiera, el [par de claves maestras](#par-de-claves-maestras) o el par de claves normales para autorizar transacciones. Puedes eliminar o reemplazar tu par de claves normales en cualquier momento sin cambiar el resto de la cuenta.
|
||||
|
||||
Un par de claves normales pueden autorizar la mayoría de tipos de transacciones que una par de claves maestras puede, con [ciertas excepciones](#pemrisos-especiales). Por ejemplo, un par de claves nomales _puede_ autorizar una transacción para cambiar el par de claves normales.
|
||||
|
||||
Una buena práctica de seguridad es guardar tu clave privada maestra en algun sitio offline, y usar un par de claves normales la mayor parte del tiempo. Como precaución, puedes cambiar el par de claves normales regularmente. Si un usuario malicioso descubre tu clave privada normal, puedes tomar el par de claves maestras de tu escondite offline y usarlo para cambiar o eliminar el par de claves normales. De este modo, puedes volver a retomar el control de la cuenta. Incluso si no eres demasiado rápido para parar al usuario malicioso de robar tu dinero, al menos no tendrás necesidad de moverte a una nueva cuenta y tener que recrear tu configuración y relaciones desde el principio.
|
||||
|
||||
El par de claves normales tiene el mismo formato que el par de claves maestras. Las generas de la misma forma (por ejemplo, usando el [método wallet_propose][]). La única diferencia es que el par de claves normales es que el par no está intrínsicamente vinculado a la cuenta para la que firma transacciones. Es posible (pero no es buena idea) utilizar el par de claves maestras de una cuenta como lel par de claves normales para otra cuenta.
|
||||
|
||||
La [transacción SetRegularKey][] asigna o cambia el par de claves normales de una cuenta. Para un tutorial de asignación o cambio de un par de claves normales, ver [Asignar par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md).
|
||||
|
||||
|
||||
## Algorítmos de firma
|
||||
|
||||
Los pares de claves criptográficas están siempre atadas a un algorítmo de firma específico, el cual define la relación matemática entre la clave secreta y la clave pública. Los algorítmos de firma criptográficos tienen la propiedad de, dado el estado actual de las técnicas de criptografía, es "fácil" utilizar una clave secreta para clacular la clave pública coincidente, pero es imposible calcular la clave secreta vinculante partiendo de la clave pública. <!-- STYLE_OVERRIDE: easy -->
|
||||
|
||||
El XRP Ledger soporta los siguientes algoritmos de firma criptográfica:
|
||||
|
||||
| Tipo de clave | Algoritmo | Descripción |
|
||||
|-------------|-----------|---|
|
||||
| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) usando la curva eliptica [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | Este es el mismo esquema que utiliza Bitcoin. El XRP Ledger utiliza este tipo de claves por defecto. |
|
||||
| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) usando la curva elíptica [Ed25519](https://ed25519.cr.yp.to/) | Este es un algoritmo más novedoso que tiene mejor rendimiento y otras propiedades convenientes. Como las claves públicas Ed25519 son un byte menos que las claves secp256k1, `rippled` prefija las claves públicas Ed25519 con el byte `0xED` así ambos tipos de claves públicas son de 33 bytes. |
|
||||
|
||||
Cuando generas un par de claves con el [método wallet_propose][], puedes especificar el `key_type` para elegir que tipo de algorítmo criptográfico se utiliza para derivar las claves. Si has generado un tipo de clave disitnto al de por defecto, debes especificar también el `key_type` cuando firmas transacciones.
|
||||
|
||||
Los tipos de pares de claves admitidos pueden utilizarse indistintatemente en todo el XRP Ledger como pares de claves maestras, pares de claves normales, y miembros de listas de firmantes. El proceso de [derivación de una dirección](addresses.md#address-encoding) es el mismo para pares de claves secp256k1 y Ed25519.
|
||||
|
||||
|
||||
### Algoritmos futuros
|
||||
|
||||
En el futuro, es posible que el XRP Ledger necesite nuevos algoritmos de firma criptográficos para mantenerse al día con el desarrollo en criptográfia. Por ejemplo, si los ordenadores cuánticos utilizasen el [algoritmo de Shor](https://en.wikipedia.org/wiki/Shor's_algorithm) (o algo similar) no tardarán en romper la curva elíptica criptográfica, los desarrolladores XRP Ledger pueden añadir un algoritmo criptográfico que no es facil de romper. A mediados de 2020, no existe un algoritmo de firma "resistente a la cuántica" y los ordenadores cuánticos no son lo suficientemente prácticos para ser una amenaza, por lo que no hay planes inmediatos para añadir algoritmos específicos. <!-- STYLE_OVERRIDE: will, easily -->
|
||||
|
||||
|
||||
## Derivación de claves
|
||||
|
||||
El proceso de derivar un par de claves depende del algoritmo de firma. En todos los casos, las claves son generadas desde un valor _seed_ (semilla) que es de 16 bytes (128 bits) de longitud. El valor semilla puede ser totalmente aleatorio (recomendado) o puede ser derivado de una passphrase específica tomando el [hash SHA-512][Hash] y manteniendo los primeros 16 bytes (como [SHA-512Half][], pero manteniendo solo 128 bits en vez de los 256 bits de la salida).
|
||||
|
||||
### Código de ejemplo
|
||||
|
||||
Los procesos de derivación de claves descritos aquí están implementados en múltiples lugares y lenguajes de programación:
|
||||
|
||||
- En C++ en el código base de `rippled`:
|
||||
- [Definición de semilla](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [Derivación de clave general & Ed25519](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [Derivación de clave secp256k1](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- En Python 3 en {% repo-link path="_code-samples/key-derivation/py/key_derivation.py" %}esta sección de códigos de ejemplo del repositorio{% /repo-link %}.
|
||||
- En JavaScript en el paquete [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs).
|
||||
|
||||
### Derivación de clave Ed25519
|
||||
[[Fuente]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Fuente")
|
||||
|
||||
[{% inline-svg file="/docs/img/key-derivation-ed25519.svg" /%}](/docs/img/key-derivation-ed25519.svg "Passphrase → Semilla → Clave secreta → Prefijo + Clave pública")
|
||||
|
||||
1. Calcular el [SHA-512Half][] del valor de la semilla. El resultado es la clave secreta de 32-byte.
|
||||
|
||||
**Consejo:** Todos los números 32-byte son válidos como claves secretas Ed25519. Sin embargo, Sin embargo, solo los números elegidos aleatoriamente son suficientemente seguros para ser usados como claves secretas.
|
||||
|
||||
2. Para calcular una clave pública Ed25519, utiliza la derivación estandar de clave pública para [Ed25519](https://ed25519.cr.yp.to/software.html) para derivar una clave pública de 32-byte.
|
||||
|
||||
**Atención:** Como con cualquier algoritmo criptográfico, utiliza una implementación estandar, reconocida y públicamente auditada cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales para Ed25519 y secp256k1.
|
||||
|
||||
3. Prefija el byte `0xED` en la clave pública 32-byte para indicar que es una clave pública Ed25519, resultando en 33 bytes.
|
||||
|
||||
Si estás impementando código para firmar transacciones, elimina el prefijo `0xED` y utiliza la clave 32-byte para el proceso de firma actual.
|
||||
|
||||
4. Cuando serializas una clave pública de cuenta a [base58][], utiliza el prefijo de la clave pública de cuenta `0x23`.
|
||||
|
||||
Las claves efímeras de validador no pueden ser Ed25519.
|
||||
|
||||
### Derivación de clave secp256k1
|
||||
[[Fuente]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Fuente")
|
||||
|
||||
[{% inline-svg file="/docs/img/key-derivation-secp256k1.svg" /%}](/docs/img/key-derivation-secp256k1.svg "Passphrase → Semilla → Par de claves inicial (Root Key Pair) → Par de claves intermedias → Par de claves maestras")
|
||||
|
||||
La derivación de claves de cuentas XRP Ledger secp256k1 involucra más pasos que con la derivación de clave Ed25519 por el siguiente par de razones:
|
||||
|
||||
- No todos los números 32-byte son válidos para claves secretas secp256k1.
|
||||
- La implementación de referencia en XRP Ledger tiene un marco incompleto y no usado para derivar una familia de claves públicas desde un valor semilla único inicial.
|
||||
|
||||
Los pasos para derivar par de claves de cuenta XRP Ledger secp256k1 desde un valor semilla es como sigue:
|
||||
|
||||
1. Calcular un par de claves iniciales (root key pair) a partir del valor semilla, como sigue:
|
||||
|
||||
1. Concatenar lo siguiente en orden, para un total de 20 bytes:
|
||||
- El valor semilla (16 bytes)
|
||||
- El valor "sequencia root" (4 bytes), como un entero big-endian no asignado. Utiliza 0 como un valor inicial para la secuencia root.
|
||||
|
||||
2. Calcular el [SHA-512Half][] del valor concatenado ( semilla+secuencia root).
|
||||
|
||||
3. Si el resultado no es una clave secreta válida secp256k1, incrementa la secuencia root en 1 y vuelve a empezar. [[Fuente]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Fuente")
|
||||
|
||||
Una clave válida secp256k1 debe no ser cero, y debe ser numericamente menor que _secp256k1 group order_. El orden grupo secp256k1 es un valor constante `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.
|
||||
|
||||
4. Con una clave secreta secp256k1 válida, utiliza la derivación de clave pública ECDSA estandar con la curva secp256k1 para derivar la clave pública inicial (root). (Como siempre para algoritmos critográficos, utiliza una implementación auditada públicamente, conocida y estandar cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones para funciones principales de Ed25519 y secp256k1.)
|
||||
|
||||
**Consejo:** Los validadores utilizan este par de claves iniciales (root). Si estás calculando un par de claves para un validador, puedes parar aquí. Para disntiguir entre estos dos tipos de claves públicas, la serialización para claves públicas de validador [base58][] usa el prefijo `0x1c`.
|
||||
|
||||
2. Convierte la clave pública inicial (root) a su forma comprimida de 33-byte.
|
||||
|
||||
La forma no comprimida de cualquier clave pública ECDSA consiste en un par de enteros de 32-byte: una coordinada X, y una coordinada Y. La forma comprimida es la coordinada X y un prefijo de one-byte: `0x02` si la coordinada Y es par, o `0x03` si la coordinada Y es impar.
|
||||
|
||||
Puedes convertir una clave pública sin comprimir a la forma comprimida desde la herramienta de línea de comandos `openssl`. Por ejemplo, si la clave pública está en el fichero `ec-pub.pem`, puedes sacar el formato comprimido de esta manera:
|
||||
|
||||
```
|
||||
$ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
|
||||
```
|
||||
|
||||
3. Deriva un "par de claves intermedio" desde la clave pública ráiz comprimida, así:
|
||||
|
||||
1. Concatena lo siguiente en orden, para un total de 41 bytes:
|
||||
- La clave pública comprimida (33 bytes)
|
||||
- `0x00000000000000000000000000000000` (4 bytes de ceros). (Este valor estaba pensado para derivar diferentes números de la misma familia, pero en la práctica solo el valor 0 es utilizado.)
|
||||
- Una valor "secuencia clave" (4 bytes), como un entero no asignado big-endian. Utiliza 0 como valor inicial para la secuencia clave.
|
||||
|
||||
2. Calcula el [SHA-512Half][] del valor concatenado.
|
||||
|
||||
3. Si el resultado noes euna clave secreta válida secp256k1, incrementa la secuencia clave en 1 y reiniciala derivación de la cuenta desde el par de claves intermedio de la cuenta.
|
||||
|
||||
4. Con una clave secreta secp256k1 válida, utiliza la derivación de clave pública ECDSA estandar con la curva secp256k1 para derivar la clave pública intermedia. (Como siempre con los algoritmos criptográficos, utiliza una implementación públicamente auditada, conocida y estandar cuando sea posible. Por ejemplo, [OpenSSL](https://www.openssl.org/) tiene implementaciones de las funciones principales Ed25519 y secp256k1.)
|
||||
|
||||
4. Deriva el par de claves públicas añadiendo la clave pública intermedia a la clave pública inicial (root). De manera similar, deriva la clave secreta añadiendo la clave secreta intermedia a la clave secreta inicial (root).
|
||||
|
||||
- Una clave secreta ECDSA es un número entero muy largo, por lo que puedes calcular la suma de dos números secretos sumando el módulo el orden de grupo secp256k1.
|
||||
|
||||
- Una clave pública ECDSA es un punto de la curva elíptica, por lo que necesitarás matemática de curva elíptica para sumar los puntos.
|
||||
|
||||
5. Convierte la clave pública maestra asu forma comprimida de 33-byte, como antes.
|
||||
|
||||
6. Cuando serialices la clave pública de la cuenta a su formato [base58][], utiliza el prefijo de la clave pública de la cuenta, `0x23`.
|
||||
|
||||
Ver [Codificación de dirección](addresses.md#address-encoding) para información y códigos de ejemplo para convertir de una clave pública de cuenta a su dirección.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Direcciones de emisión y operacionales](account-types.md)
|
||||
- **Tutoriales:**
|
||||
- [Asignación de par de claves normales](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
|
||||
- [Cambiar o eliminar par de claves normales](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
|
||||
- **Referencias:**
|
||||
- [Transacción SetRegularKey][]
|
||||
- [Objeto de ledger AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
- [método wallet_propose][]
|
||||
- [método account_info][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
html: decentralized-identifiers.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
|
||||
status: not_enabled
|
||||
labels:
|
||||
- DID
|
||||
---
|
||||
# Identificadores descentralizados
|
||||
|
||||
_(REquiere de la [enmienda DID][] {% not-enabled /%})_
|
||||
|
||||
Un identificador descentralizado (DID) es un nuevo tipo de identificador definido por el World Wide Web Consortium (W3C) que permite identidades digitales verificables. Los DIDs están completamente bajo el control del dueño del DID, independientemente de cualquier registro centralizado, proveedor de identidad, o autoridad certificada.
|
||||
|
||||
Los principios clave de un DID son:
|
||||
|
||||
- **Descentralizacion:** No hay una agencia emisora central que controla el DID, lo que permite al propietario actualizar, resolver o desactivarlo.
|
||||
|
||||
- **Criptográficamente verificable:** Los DIDs son verificados a través de pruebas criptográficas, lo que los hace a prueba de manipulaciones y seguros.
|
||||
|
||||
- **Interoperabilidad:** Los DIDs están abiertos a cualquier solución que reconozca el estandar W3C DID. Esto quiere decir que un DID puede ser utilizado para autenticar y establecer confianza en varias transacciones digitales e interacciones.
|
||||
|
||||
**Nota:** La implementación de DIDs en el XRP Ledger cumple con los requisitos de la [especificación DID v1.0](https://www.w3.org/TR/did-core/).
|
||||
|
||||
|
||||
## Cómo funciona
|
||||
|
||||
1. El dueño de una cuenta XRPL genera un DID que es controlado por la cuenta.
|
||||
2. El DID se asocia a un documento DID definido por la especificaciones W3C.
|
||||
3. El DID es usado para las siguientes tareas digitales como:
|
||||
- Firmar documentos digitales.
|
||||
- Realizar transacciones en linea seguras.
|
||||
- Iniciar sesión en sitios web.
|
||||
4. El verificador resuelve el DID a su docuemnto para verificar la identidad del sujeto.
|
||||
|
||||
|
||||
## Documentos DID
|
||||
|
||||
Los documentos DID contienen la información necesaria para verificar criptográficamente la identidad del sujeto descrito por el documento DID. El sujeto puede ser una persona, organización, o cosa. Por ejemplo, un documento DID podría contener claves criptográficas públicas que el sujeto DID puede utilizar para autenticarse y demostrar su asociación con el DID.
|
||||
|
||||
**Nota:** Los documentos DID suelen serializarse en una representación JSON o JSON-LD.
|
||||
|
||||
En el XRP Ledger, hay numerosas formas de asociar un DID a un documento DID:
|
||||
|
||||
1. Almacenar una referencia al documento en el campo `URI` del objeto `DID`, que apunta al documento almacenado en otra red de almacenamiento descentralizado, como es IPFS o STORJ.
|
||||
2. Almacenar un documento DID mínimo en el campo `DIDDocument` del objeto `DID`.
|
||||
3. Utilizar un documento DID _implicito_ generado a partir del DID y otra información pública disponible.
|
||||
**Nota:** Los casos de uso más simples pueden solo necesitar firmas y rokens de autorización simples. En casos donde no haya un documento DID explicitamente en el ledger, un documento implicito es utilizado en su lugar. Por ejemplo, el documento DID de `did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` habilita solo la clave única `0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020` para autorizar cambios en el documento DID o firmar credenciales en nombre del DID.
|
||||
|
||||
|
||||
### Ejemplo de documento DID XRPL
|
||||
|
||||
```json
|
||||
{
|
||||
"@context": "https://w3id.org/did/v1",
|
||||
"id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"publicKey": [
|
||||
{
|
||||
"id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
|
||||
"type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
|
||||
"curve": "secp256k1",
|
||||
"expires": 15674657,
|
||||
"publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Para aprender más sobre las propiedades principales de un documento DID, ver: [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/#core-properties).
|
||||
|
||||
|
||||
## Precauciones de privacidad y seguridad
|
||||
|
||||
- Quien controla las claves privadas de la cuenta XRPL, controla el DID y las referencias al documento DID a la que resuelve. Asegúrate de que tus claves privadas no se comprometan.
|
||||
- Puedes incluir cualquier contenido en un documento DID, pero deberías limitarlo a métodos de verificación y puntos de servicio. Como los DIDs en XRPL pueden ser resueltos por cualquiera, no deberías introducir ninguna información personal.
|
||||
- IPFS permite a cualquiera almacenar contenido en los nodos de una red distribuida. Un error común es que cualquiera puede editar ese contenido; sin embargo, la capacidad de direccionamiento del contenido de IPFS significa que cualquier contenido editado tendrá una dirección diferente a la original. Mientras que cualquier entidad puede copiar un documento DID anclado a los campos `DIDDocument` o `URI` de una cuenta XRPL, no pueden cambiar el documento en sí a menos que controlen la clave privada que creó el objeto `DID`.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
38
@i18n/es-ES/docs/concepts/accounts/deleting-accounts.md
Normal file
38
@i18n/es-ES/docs/concepts/accounts/deleting-accounts.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
html: deleting-accounts.html
|
||||
parent: accounts.html
|
||||
blurb: Acerca de eliminar una cuenta XRP Ledger.
|
||||
labels:
|
||||
- Cuentas
|
||||
---
|
||||
# Eliminar Cuentas
|
||||
|
||||
El dueño de una cuenta puede enviar una [transacción AccountDelete][] para eliminar la cuenta y las entradas relativas del ledger, enviando la mayoría del XRP en balance restante a otra cuenta. Para evitar la creación y eliminación de cuentas sin sentido, eliminar una cuenta requiere quemar una cantidad superior a la usual utilizada como [coste de transacción](../transactions/transaction-cost.md).
|
||||
|
||||
Algún tipo de entradas asociadas al ledger bloquean a una cuenta de ser eliminada. Por ejemplo, el emisor de un token fungible no puede ser borrad mientras cualquiera teng un saldo distinto a cero de ese token como balance.
|
||||
|
||||
Una vez una cuenta ha sido eliminada, puede ser recreada en el eldger a través de un método normal de [creación de cuentas](index.md#creating-accounts). Una cuenta que ha sido eliminada y re-creada no es diferente de una cuenta que ha sido creada por primera vez.
|
||||
|
||||
## Requisitos
|
||||
|
||||
Para ser eliminada, una cuenta debe cumplir los siguientes requisitos:
|
||||
|
||||
- El número de `Sequence` de la cuenta más 256 debe ser menor que el [Índice del ledger][] actual.
|
||||
- La cuenta no debe estar enlazada a de los siguientes tipos de [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md) (como remitente o destinatario):
|
||||
- `Escrow`
|
||||
- `PayChannel`
|
||||
- `RippleState`
|
||||
- `Check`
|
||||
- La cuenta debe tener menos de 1000 objetos en el ledger.
|
||||
- La transacción debe pagar un [coste de transacción][] especial igual al menos a la [reserva de propietario](reserves.md) de un artículo (actualmente 2 XRP).
|
||||
|
||||
## Coste de eliminación
|
||||
|
||||
**Atención:** El coste de transacción de la [transacción AccountDelete][] siempre aplica cuando la transacción está incluida en un ledger validado, incluso si la transacción falla porque la cuenta no reune los requisitos para ser eliminada. Para reducir las posibilidades de pagar un coste de transacción alto si la cuenta no puede ser eliminada, utiliza la opción `fail_hard` cuando envíes una transacción AccountDelete.
|
||||
|
||||
A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la cadena del ledger público de XRP Ledger contiene el estado completo del ledger, lo cual incrementa en tamaño con cada cuenta nueva. Por esa razón, no deberías crear nuevas cuentas XRP Ledger si no tienes necesidad. Puedes recuperar parte de los 10 XRP de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos 2 XRP haciéndolo.
|
||||
|
||||
Instituciones que reciben y envían valor en nombre de muchos usuarios pueden utilizar [**Source Tags** y **Destination Tags**](../transactions/source-and-destination-tags.md) para distinguir pagos desde y para sus clientes usando una (o un puñado) de cuentas en el XRP Ledger.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
119
@i18n/es-ES/docs/concepts/accounts/depositauth.md
Normal file
119
@i18n/es-ES/docs/concepts/accounts/depositauth.md
Normal file
@@ -0,0 +1,119 @@
|
||||
---
|
||||
html: depositauth.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: La configuración DepositAuth le permite a una cuenta bloquear pagos entrantes por defecto.
|
||||
labels:
|
||||
- Pagos
|
||||
- Seguridad
|
||||
---
|
||||
# Autorización para depositar
|
||||
|
||||
_(Añadido por la [enmienda DepositAuth][].)_
|
||||
|
||||
La Autorización para depositar es una configuración opcional de la [cuenta](index.md) en el XRP Ledger. Si se activa, La Autorización para depositar, bloquea todas las transferencias de desconocidos, incluidas las transferencias de XRP o [tokens](../tokens/index.md). Una cuenta con Autorización para depositar solo puede recibir valor de dos maneras:
|
||||
|
||||
- Desde cuentas que tiene [preautorizadas](#preautorización).
|
||||
- Enviando una transacción para recibir los fondos. Por ejemplo, una cuenta con Autorización para depositar puede finalizar un [Escrow](../payment-types/escrow.md) que fue iniciado por un desconocido.
|
||||
|
||||
Por defecto, las cuentas nuevas tienen DepositAuth desactivado y pueden recibir XRP de cualquiera.
|
||||
|
||||
## Trasfondo
|
||||
|
||||
Las regulaciones y licencias para servicios financieros pueden requerir a un negocio o entidad que deba conocer al remitente de todas las transacciones que recibe. Esto presenta un desafio en un sistema descentralizado como el XRP Ledger donde participantes son identificados con pseudónimos que son libremente generados y el comportamiento predeterminado es que cualquier dirección puede pagar a otra.
|
||||
|
||||
La marca (flag) de Deposit Authorization introduce una opción para aquellos que utilizan el XRP Ledger para cumplir con las regulaciones sin cambiar la naturaleza fundamental del ledger descentralizado. Con La Autorización para depositar activada, una cuenta solo puede recibir fondos explícitamente aprobados enviando una transacción. El dueño de la uenta utilizando Deposit Authorization puede realizar la diligencia necesaria para identificar al remitente de cualquier fondo _antes_ de enviar la transacción que cuasa que la cuenta reciba el dinero.
|
||||
|
||||
Cuando tienes la opción Deposit Authorization activada, puedes recibir dinero de [Checks](/resources/known-amendments.md#checks), [Escrow](../payment-types/escrow.md), y [Payment Channels](/resources/known-amendments.md#paychan). En esas transacciones de tipo "dos pasos", primero el origen manda una transacción para autorizar los fondos, después el destinatario manda una transacción que autoriza recibir esos fondos.
|
||||
|
||||
Para recibir dinero de [transacciones Payment][] cuando tienes la opción Deposit Authorization activada, debes [preautorizar](#preautorización) los remitentes de esos Payments. _(Añadido por la [enmienda DepositPreauth][].)_
|
||||
|
||||
## Uso recomendado
|
||||
|
||||
Para conseguir un efecto total de Deposit Authorization, Ripple recomienda además hacer lo siguiente:
|
||||
|
||||
- Siempre mantener un balance en XRP superior al mínimo del [requisito de reserva](reserves.md).
|
||||
- Mantener la marca (flag) Default Ripple en su estado por defecto (desactivada). No actives [rippling](../tokens/fungible-tokens/rippling.md) en ninguna trust lines. Cuando envíes [transacciones TrustSet][], siempre utiliza el [flag `tfSetNoRipple`](../../references/protocol/transactions/types/trustset.md).
|
||||
- No crees [Offers](../../references/protocol/transactions/types/offercreate.md). Es imposible conocer de antemano que ofertas coincidentes serán utilizadas para ejecutar dicha operación. <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
## Precisión en la semántica
|
||||
|
||||
Una cuenta con Deposit Authorization activado:
|
||||
|
||||
- **No puede** ser destinatario de [transacciones Payment][], con **las siguientes excepciones**:
|
||||
- Si el destinatario tiene [preautorizado](#preautorización) al remitente del pago. _(Añadido con la [enmienda DepositPreauth][])_
|
||||
- Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente 10 XRP). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
|
||||
- Puede recibir XRP de [transacciones PaymentChannelClaim][] **únicamente en los siguientes casos**:
|
||||
- El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
|
||||
- El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_
|
||||
- Puede recibir XRP de [transacciones EscrowFinish][] **únicamente en los siguientes casos**:
|
||||
- El remitente de una transacción EscrowFinish es el destino de un escrow.
|
||||
- El destino de una transacción EscrowFinish tiene [preautorizado](#preautorización) al remitente de un EscrowFinish. _(Añadido en la [enmienda DepositPreauth][])_
|
||||
- **Puede** recibir XRP o tokens enviando una transacción [CheckCash][]. _(Añadido por la [enmienda Checks][].)_
|
||||
- **Puede** recibir XRP o tokens enviando [transacciones OfferCreate][].
|
||||
- Si la cuenta envía una transacción OfferCreate que no está completamente ejecutada in mediatamente, **puede** recibir el resto del XRP o token solicitado después cuando la oferta sea consumida por otras transacciones [Payment][] y [OfferCreate][] de la cuenta.
|
||||
- Si la cuenta ha creado cualquier línea de confianza (trust lines) sin la marca [No Ripple flag](../tokens/fungible-tokens/rippling.md) activada, o ha activado el flag Default Ripple y emitido una moneda, la cuenta **puede** recibir los tokens de esas trust lines en [transacciones Payment][] como resultado del rippling. No puede ser el destino de esas transacciones.
|
||||
- En general, una cuenta en el XRP Ledger **no puede** recibir divisas no-XRP en el XRP Ledger mientras que lo siguiente sea cierto. (Esta regla no es específica del flag DepositAuth.)
|
||||
- La cuenta no ha creado trust lines con límites distintos a cero.
|
||||
- La cuenta no ha emitido tokens en trust lines creadas por otros.
|
||||
- La cuenta no ha generado ninguna oferta.
|
||||
|
||||
La siguiente tabla resume cuando un tipo de transacción puede depositar dinero con DepositAuth activado o desactivado:
|
||||
|
||||
{% partial file="/docs/_snippets/depositauth-semantics-table.md" /%}
|
||||
|
||||
|
||||
|
||||
## Activar o desactivar Deposit Authorization
|
||||
|
||||
Una cuenta puede activar la autorización de depositar enviando una [transacción AccountSet][] con el campo `SetFlag` con el valor de `asfDepositAuth` (9). La cuenta puede desactivar la autorización de depositar enviando una [transacción AccountSet][] con el campo `ClearFlag` con el valor de `asfDepositAuth` (9). Para más información sobre flags en AccountSet, consultar [AccountSet flags](../../references/protocol/transactions/types/accountset.md).
|
||||
|
||||
## Comprobar cuando una cuenta tiene DepositAuth activado
|
||||
|
||||
Para ver cuando una cuenta tiene Deposit Authorization activado, utiliza el [método account_info][] para mirar en la cuenta. Compara el valor de los campos `Flags` (en el objeto `result.account_data`) con los [bitwise flags definidos para un objeto de ledger AccountRoot ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md).
|
||||
|
||||
Si el resultado de los valores bitwise `Flags` Y el valor del flag `lsfDepositAuth` (`0x01000000`) es distinto a cero, entonces la cuenta tiene el DepositAuth activado. Si el resultado es cero, entonces la cuenta tiene DepositAuth desactivado.
|
||||
|
||||
## Preautorización
|
||||
|
||||
_(Añadido por la [enmienda DepositPreauth][].)_
|
||||
|
||||
Las cuentas con DepositAuth activado pueden _preautorizar_ ciertos remitentes, para permitir pagos desde esos remitentes sean realizados aunque DepositAuth esté activado. Eseto permite a remitentes específicos enviar directamente fondos sin que el que vaya recibirlos tenga que tomar una acción para cada transacción individualmente. La preautorización no es obligatoria para usar DepositAuth, pero puede hacer ciertas opereaciones más sencillas.
|
||||
|
||||
La preautorización es agnóstica en cuanto a divisas. No puede preautorizar cuentas para solo una moneda específicamente.
|
||||
|
||||
Para preautorizar a un remitente en particular, envía una [transacción DepositPreauth][] con la dirección de otra cuenta para preautorizar en el campo `Authorize`. Para revocar la preautorización, facilita la dirección de la otra cuenta en el campo `Unauthorize`. Especifica tu propia dirección en el campo `Account` como de normal. Puedes preautorizar o desautorizar cuentas incluso si acutalmente no tienes activado DepositAuth; el estado preautorización que seleccionas para otras cuentas se guarda, pero no tiene efecto a no ser que actives DepositAuth. Una cuenta no puede preautorizarse a si misma. Las preautorizaciones son unidireccionales, y no tienen efecto en pagos que van en la otra dirección.
|
||||
|
||||
Preautorizar otra cuenta añade un [objeto DepositPreauth](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md) al ledger, el cual incrementa la [reserva del propietario](reserves.md#owner-reserves) de la cuenta que provee la autorización. Su la cuenta revoca la preautorización, elimina el objeto y hace decrecer las reservas del propietario.
|
||||
|
||||
Una vez que la transacción DepositPreauth ha sido procesada, la cuenta autorizada puede enviar fondos a tu cuenta, incluso si tienes DepositAuth activado, usando cualquiera de los siguientes tipos de transacción:
|
||||
|
||||
- [Payment][]
|
||||
- [EscrowFinish][]
|
||||
- [PaymentChannelClaim][]
|
||||
|
||||
Las preautorización no tiene efecto sobre las otras formas de enviar dinero a una cuenta con DepositAuth activado. Ver [Precisión en la semántica](#precise-semantics) para las reglas exactas.
|
||||
|
||||
### Comprobar la autorización
|
||||
|
||||
Puedes utilizar el [método deposit_authorized][] para ver si una cuenta esta autorizada para despositar en otra cuenta. Este método comprueba dos cosas: <!-- STYLE_OVERRIDE: is authorized to -->
|
||||
|
||||
- Si la cuenta de destino requiere de Deposit Authorization. (Si no requiere de autorización, todas las cuentas de origen son consideradas autorizadas.)
|
||||
- Si la cuenta de origen es preautorizada para enviar dinero al destino.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- La referencia [transación DepositPreauth][].
|
||||
- El [tipo de objeto del ledger DepositPreauth](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md).
|
||||
- El [método deposit_authorized][] de la [API `rippled`](../../references/http-websocket-apis/index.md).
|
||||
- La característica [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md) (`RequireAuth` flag) limita que contrapartes pueden poseer divisas no-XRP en la cuenta.
|
||||
- El flag `DisallowXRP` indica que una cuenta no puede recibir XRP. Es una protencción más suave que Deposit Authorization, y no la aplica el XRP Ledger. (Las aplicaciones cliente deberían respetar este flag o al menos avisar de ello.)
|
||||
- El flag `RequireDest` indica que una cuenta solo puede recibir cantidades de divisas si se especifica un [Destination Tag](../transactions/source-and-destination-tags.md). Esto protege a usuarios de olvidar incluir el propósito del pago, pero no protege a los destinatarios de remitentes desconocidos que pueden añadir destination tags arbitrarios.
|
||||
- [Pagos parciales](../payment-types/partial-payments.md) provee una forma para que cuentas puedan devolver pagos no deseados restando los [costes de transferencia](../tokens/transfer-fees.md) y los ratios de exchanges de la cantidad enviada en lugar de sumarlos a la cantidad enviada.
|
||||
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
|
||||
|
||||
|
||||
[enmienda DepositPreauth]: /resources/known-amendments.md#depositpreauth
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
69
@i18n/es-ES/docs/concepts/accounts/index.md
Normal file
69
@i18n/es-ES/docs/concepts/accounts/index.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
html: accounts.html
|
||||
parent: concepts.html
|
||||
seo:
|
||||
description: Aprende sobre cuentas en el XRP Ledger. AccouLas cuentas pueden enviar transacciones y almacenar XRP.
|
||||
labels:
|
||||
- Cuentas
|
||||
- Pagos
|
||||
---
|
||||
# Cuentas
|
||||
|
||||
Una "Cuenta" en el XRP Ledger representa a un titular de XRP y a un emisor de [transacciones](../../references/protocol/transactions/index.md).
|
||||
|
||||
Una cuenta consiste en una dirección, un balance en XRP, un número de secuencia y un historial de sus transacciones. Para poder enviar transacciones, el dueño también necesita uno o más pares de claves criptográficas asociadas con la cuenta.
|
||||
|
||||
|
||||
## Estructura de la cuenta
|
||||
|
||||
Los elementos principales de una cuenta son:
|
||||
|
||||
- Una **cuenta** identificable, como `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`.
|
||||
- Un **balance en XRP**. Parte de este XRP se aparte para la [Reserva](reserves.md).
|
||||
- Un **número de secuencia**, el cual ayuda a asegurar que cualquier transacción que esta cuenta envíe se aplique en el orden correcto y solo una vez. Para ejecutar una transacción, el número de secuencia de la transacción y el número de secuencia de su remitente deben coincidir. Después, como parte de la aplicación de la transacción, el número de secuencia de la cuenta incrementa en 1. (Ver también: [Tipos de datos básicos: Secuencia de cuenta](../../references/protocol/data-types/basic-data-types.md#account-sequence).)
|
||||
- Un **histórico de transacciones** que afectaron a la cuenta y sus balances.
|
||||
- Una o más maneras de [autorizar transacciones](../transactions/index.md#authorizing-transactions), posiblemente incluyendo:
|
||||
- Un par de claves maestras intrínseco a la cuenta. (Esto puedes desactivarse pero no cambiarse.)
|
||||
- Una par de claves "normales" ("regular" en inglés) que se pueden rotar.
|
||||
- Una lista de firmantes para [multi-firma](multi-signing.md). (Almacenado por separado de los datos principales de la cuenta.)
|
||||
|
||||
Los datos principales de una cuenta se guardan en una entrada del ledger [AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md). Una cuenta puede ser también el dueña (o parcialmente dueña) de varios otros tipos de entradas del ledger.
|
||||
|
||||
**Consejo:** Una "Cuenta" en el XRP Ledger está en algún lugar entre el uso financiero (como una "cuenta bancaria") y el uso informático (como una "cuenta UNIX"). Las monedas y activos no XRP no se guardan en una cuenta del XRP Ledger en sí misma; cada uno de estos activos se almacena en una relación contable llamada "Línea de confianza" (trust line en inglés) que conecta a dos partes.
|
||||
|
||||
|
||||
## Creación de cuentas
|
||||
|
||||
No hay una transacción dedicada a "crear una cuenta". La [transacción Payment][] automáticamente crea una nueva cuenta si el pago envía suficiente XRP a una dirección matemáticamente válida que aún no tiene una cuenta. Esto se llama _finnaciar_ una cuenta, y crea una [entrada AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) en el ledger. No hay otra transacción que cree una cuenta.
|
||||
|
||||
**Atención:** Financiar una cuenta **no te da** privilegios especiales sobre esa cuenta. Quien tenga la clave secreta correspondiente a la dirección de la cuenta tiene control total sobre la cuenta y todo el XRP que contiene. Para algunas direcciones, es posible que nadie tenga la clave secreta, en este caso la cuenta es un agujero negro [black hole](addresses.md#special-addresses) y el XRP se pierde para siempre.
|
||||
|
||||
La forma típica de obtener una cuenta en el XRP Ledger es la siguiente:
|
||||
|
||||
1. Genera un par de claves desde una fuente de fuerte aleatoriedad y calcula la dirección de ese par de claves.
|
||||
|
||||
2. Hacer que alguien que ya tenga una cuenta en el XRP Ledger envíe XRP a la dirección que generaste.
|
||||
|
||||
- Por ejemplo, puedes comprar XRP en un exchange privado, después retirar el XRP del exchange a la dirección que especificaste.
|
||||
|
||||
**Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente 10 XRP), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
|
||||
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Reservas](reserves.md)
|
||||
- [Claves criptográficas](cryptographic-keys.md)
|
||||
- [Cuentas emisoras y operacionales](account-types.md)
|
||||
- **Referencias:**
|
||||
- [Método account_info][]
|
||||
- [Método wallet_propose][]
|
||||
- [Transacción AccountSet][]
|
||||
- [Transacción Payment][]
|
||||
- [Objeto AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
- **Tutoriales:**
|
||||
- [Administrar configuración de la cuenta (Categoría)](../../tutorials/how-tos/manage-account-settings/index.md)
|
||||
- [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
86
@i18n/es-ES/docs/concepts/accounts/multi-signing.md
Normal file
86
@i18n/es-ES/docs/concepts/accounts/multi-signing.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
html: multi-signing.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Utiliza la firma múltiple para mayor seguridad enviando transacciones.
|
||||
labels:
|
||||
- Smart Contracts
|
||||
- Seguridad
|
||||
---
|
||||
# Multi-Signing
|
||||
|
||||
La firma múltiple o multi-signing en el XRP Ledger es un método para [autorizar transacciones](../transactions/index.md#authorizing-transactions) para el XRP Ledger usando una combinación de múltiples claves secretas. Puedes tener cualquier combinación de métodos de autorización activados para tu dirección, incluido el multi-signing, un [par de claves maestras](cryptographic-keys.md#par-de-claves-maestras), y un [par de claves normales](cryptographic-keys.md#par-de-claves-normales). (El único requisito es que _al menos un_ método debe estar activado.)
|
||||
|
||||
Los beneficios del multi-signing incluyen:
|
||||
|
||||
- Puedes requerir claves de distintos dispositivos, por lo que un actor malicioso deberá comprometer múltiples dispositivos para enviar transacciones en tu nombre.
|
||||
- Puedes compartir la custodia de una cuenta entre varias personas, cada una de las cuales tiene una de las varias claves necesarias para enviar transacciones desde esa dirección.
|
||||
- Puedes delegar el poder de enviar transacciones desde una dirección a un grupo de personas, puedes controlar tu dirección si no estás disponible o no puedes firmar normalmente.
|
||||
|
||||
## Las listas de firmantes
|
||||
|
||||
Antes de poder hacer multi-sign, debes crear una lista de direcciones que pueden firmar por ti.
|
||||
|
||||
La [transacción SignerListSet][] define una _lista de firmantes_, un conjunto de direcciones que pueden autorizar una transacción desde tu dirección. Puedes incluir de 1 a 32 direcciones en la lista de firmantes. La lista no puede incluir tu dirección y no se puede duplicar las entradas. Puedes controlar cuantas firmas son necesarias, en que combinaciones, utilizando las opciones _Signer Weight_ (Peso de firmante) y _Quorum_ en la lista.
|
||||
|
||||
_(Actualizado por la [enmienda ExpandedSignerList][].)_
|
||||
|
||||
### Peso del firmante
|
||||
|
||||
Asignas un peso a cada firmantes de la lista. El peso representa la autoridad del firmante relativa a otros firmantes de la lista. Mientras más alto el valor, más autoridad. Los pesos individuales no pueden exceder 2<sup>16</sup>-1.
|
||||
|
||||
### Cuórum
|
||||
|
||||
El valor cuórum de una lista es una peso mínimo total requerido para autorizar la transacción. El cuórum debe ser mayor a 0 pero menor o igual a la suma de los valores de los pesos en la lista de firmantes: lo que significa, que debe ser posible conseguir un cuórum con los pesos de firmante dados.
|
||||
|
||||
### Localizador de cartera
|
||||
<!-- STYLE_OVERRIDE: wallet -->
|
||||
|
||||
También puedes añadir hasta 256 bits de datos arbitrarios para cada entrada por firmante de la lista. Estos datos no son necessarios o usados por la red, pero pueden ser utilizados por smart contracts u otras aplicaciones para identificar o confirmar otros datos sobre los firmantes.
|
||||
|
||||
_(Añadido en la [enmienda ExpandedSignerList][].)_
|
||||
|
||||
|
||||
### Ejemplos uitilzando Signer Weight y Quorum
|
||||
|
||||
Los pesos y el cuórum te permiten establecer un nivel apropiado de supervisión para cada transacción, en función de la confianza relativa y la autoridad relegada a los responsables que administran la cuenta.
|
||||
|
||||
Para un caso de uso de una cuenta compartida, deberías crear una lista con un cuórum de 1, luego dar a todos los participantes un peso de 1. Una sola aprobación de uno de los participantes es necesario para aprobar una transacción.
|
||||
|
||||
Para una cuenta muy importante, puedes configurar un cuórum de 3, con 3 partiicpantes que tienen un peso de 1. Todos los participantes deben estar de acuerdo y aprobar su transacción.
|
||||
|
||||
Otra cuenta también podría tener un cuórum de 3. Asignas a tu CEO un peso de 3, 3 vicepresidentes un peso de 2 a cada uno, y 3 directores un peso de 1 a cada uno. Para aprobar una transacción en esta cuenta se requiere la aprobación de los 3 directores (peso total de 3), 1 vicepresidente y 1 director (peso total de 3), 2 vicepresidentes (peso total de 4), o del CEO (peso total de 3). <!-- STYLE_OVERRIDE: vice -->
|
||||
|
||||
En cada uno de los tres ejemplos anteriores, deshabilitarías la clave maestra sin configurar la clave normal, así la única forma de [autorizar transactiones](../transactions/index.md#authorizing-transactions) es el multi-signing.
|
||||
|
||||
Podría darse el caso donde crees una lista de multi firma como "plan de respaldo". El dueño de la cuenta normalmente usa la clave normal para sus transacciones (no una clave multi-signing). Por seguridad, el propietario añade una lista de firmantes que contiene a 3 amigos, los tres con un peso de 1, y un cuórum de 3. Si el propietario de la cuenta perdiese la clave privada, puede pedir a sus amigos que multi firmen una transacción para reemplazar la clave normal.
|
||||
|
||||
|
||||
## Mandar transacciones Multi-Signed
|
||||
|
||||
Para enviar transacciones multi-signed de forma satisfactoria, debes de hacer todo lo siguiente:
|
||||
|
||||
* La dirección que envía la transacción (especificada en el campo `Account`) debe tener un [objeto `SignerList` en el ledger ](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md). Para instrucciones de cómo hacer esto, ver [Set Up Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md).
|
||||
* La transacción debe incluir el campo `SigningPubKey` como un valor vacío.
|
||||
* La transacción debe incluir el [campo `Signers`](../../references/protocol/transactions/common-fields.md#signers-field) conteniendo un array de firmas.
|
||||
* Las firmas presentadas en el array `Signers` debe coincidir con los firmantes definidos en la `SignerList`.
|
||||
* Para las firmas presentadas, el peso total asociado con esos firmantes debe ser igual o mayor al cuórum de la `SignerList`.
|
||||
* El [coste de transacción](../transactions/transaction-cost.md) (especificado en el campo `Fee`) debe ser al menos (N+1) veces el coste de una transacción normal, donde N es el número de firmas presentadas.
|
||||
* Todos los campos de la transacción deben ser definidos antes de recolectar las firmas. No puedes [auto-rellenar](../../references/protocol/transactions/common-fields.md#auto-fillable-fields) los campos.
|
||||
* Si se presenta en forma binaria, el array de `Signers` debe estar ordenado en base al valor números de las direcciones de los firmantes, con el valor menor, primero . (Si se envía como JSON, el [método submit_multisigned][] se ocupa de ello automáticamente.)
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Tutoriales:**
|
||||
- [Configurar Multi-Signing](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
|
||||
- [Envíar una transacción Multi-Signed](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
|
||||
- **Conceptos:**
|
||||
- [Claves criptográficas](cryptographic-keys.md)
|
||||
- [Coste de transacción especial para transacciones Multi-signed](../transactions/transaction-cost.md#special-transaction-costs)
|
||||
- **Referencias:**
|
||||
- [Transacción SignerListSet][]
|
||||
- [Objeto SignerList](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
|
||||
- [método sign_for][]
|
||||
- [método submit_multisigned][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
81
@i18n/es-ES/docs/concepts/accounts/reserves.md
Normal file
81
@i18n/es-ES/docs/concepts/accounts/reserves.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
html: reserves.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Las cuentas XRP Ledger exigen una reserva de XRP para reducir el spam en la información del ledger.
|
||||
labels:
|
||||
- Comisiones
|
||||
- Cuentas
|
||||
top_nav_grouping: Páginas populares
|
||||
---
|
||||
# Reservas
|
||||
|
||||
El XRP Ledger aplica un _requisito de reserva_, en XRP, para proteger el ledger global compartido de crecer excesivamente como resultado del spam o del uso malicioso. El objetivo es limitar el crecimiento del ledger para coincida con las mejoras tecnológicas de tal forma que un equipo basico actual pueda siempre tener el ledger actual en RAM.
|
||||
|
||||
Para tener una cuenta, una dirección debe tener una cantidad mínima de XRP en el ledger global compartido. Para financiar una nueva dirección, debes recibir el suficiente XRP en la dirección para coincidir con el requisito de reserva. No puedes enviar el XRP reservado a otros, pero puedes recuperar parte del XRP si [eliminas la cuenta](deleting-accounts.md).
|
||||
|
||||
El requisito de reserva cambia de tanto en tanto debido al proceso de [Votación de fees](../consensus-protocol/fee-voting.md), donde los validadores pueden estar de acuerdo con nuevas configuraciones de reservas.
|
||||
|
||||
## Reserva base y reserva de propietario
|
||||
|
||||
Los requisito de reserva consta de dos partes:
|
||||
|
||||
* La **reserva base** es la cantidad mínima de XRP que es necesaria para cada dirección en el ledger.
|
||||
* La **reserva de propietario** es un incremento del requisito de reserva por cada objeto que la dirección posee en el ledger. El coste por artículo se le conoce como _reserva incremental_.
|
||||
|
||||
Los requerimientos de reserva actuales en Mainnet son:
|
||||
|
||||
- Reserva base: **10 XRP**
|
||||
- Reserva de propietario: **2 XRP** por artículo
|
||||
|
||||
Reservas en otras redes pueden variar.
|
||||
|
||||
## Reservas de propietario
|
||||
|
||||
Muchos objetos en el ledger (entradas en el ledger) pertenecen a una cuenta en particular. Normalmente, el propietario es una cuenta que ha creado el objeto. Cada objeto aumenta el requisito de reserva total en la reserva de propietario. Cuando los objetos son eliminados del ledger, ya no cuentan para el requisito de reserva.
|
||||
|
||||
Los objetos que cuentan para el requisito de de reserva de su propietario son: [Cheques](../payment-types/checks.md), [Preatutorizaciones para depositar](depositauth.md#preauthorization), [Escrows](../payment-types/escrow.md), [Ofertas NFT](../tokens/nfts/trading.md), [Páginas NFT](../tokens/nfts/index.md), [Ofertas](../../references/protocol/ledger-data/ledger-entry-types/offer.md), [Canales de pago](../payment-types/payment-channels.md), [Listas de firmantes](multi-signing.md), [Tickets](tickets.md), y [Trust Lines](../tokens/fungible-tokens/index.md).
|
||||
|
||||
Algunos casos especiales:
|
||||
|
||||
- Non-Fungible Tokens (NFTs) están agrupados en páginas que contienen hasta 32 NFTs en cada una, y la reserva de propietario aplica por página más que por NFT. Debido al mecanismo para dividir y combinar páginas, la cantidad de NFTs almacenados por página puede variar. Ver también: [Reserva para objetos NFTokenPage](../../references/protocol/ledger-data/ledger-entry-types/nftokenpage.md#nftokenpage-reserve).
|
||||
- Trust lines (entradas `RippleState`) son compartidas entre dos cuentas. La reserva del propietario puede aplicar a una o ambas. La mayoría de veces, el poseedor del token debe una reserva y el emisor no. Ver también: [RippleState: Contribuyendo a las reservas de propietario](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#contributing-to-the-owner-reserve).
|
||||
- Listas de firmantes creadas antes de la [enmienda MultiSignReserve][] activada en abril de 2019 cuentacon múltiples objetos. Ver también: [Listas de firmantes y reservas](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md#signer-lists-and-reserves).
|
||||
- Un [Directorio de propietario](../../references/protocol/ledger-data/ledger-entry-types/directorynode.md) es una entrada del ledger que lista todos los objetos relacionados a una cuenta, incluyendo toods los objetos que la cuenta posee. Sin embargo, el directorio del propietario en sí no cuenta para la reserva.
|
||||
|
||||
### Buscando las reservas
|
||||
|
||||
Las aplicaciones pueden buscar los valores de las reservas base e incremental actuales utilizando el [método server_info][] o el [método server_state][]:
|
||||
|
||||
| Método | Unidades | Campo de reserva base | Campo de reserva incremental |
|
||||
|-------------------------|----------------------|-------------------------------------|------------------------------------|
|
||||
| [método server_info][] | Decimal XRP | `validated_ledger.reserve_base_xrp` | `validated_ledger.reserve_inc_xrp` |
|
||||
| [método server_state][] | Drops enteros de XRP | `validated_ledger.reserve_base` | `validated_ledger.reserve_inc` |
|
||||
|
||||
Para determinar las reservas de propietario de una cuenta, hay que multiplicar la reserva incremental por el número de objetos que la cuenta posee. Para mirar el número de objetos que una cuenta posee, llama al [método account_info][] y toma `account_data.OwnerCount`.
|
||||
|
||||
Para calcular el requisito total de direcciones, multiplica `OwnerCount` por `reserve_inc_xrp`, y luego suma `reserve_base_xrp`. [Aquí tienes una demostración](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#codeblock-17) del cálculo en Python.
|
||||
|
||||
|
||||
## Quedarse por debajo del requisito de reserva
|
||||
|
||||
Durante el procesamiento de transacciones, el [coste de transacción](../transactions/transaction-cost.md) destruye parte del XRP del saldo de la dirección que envía la transacción. Esto puede causar que una dirección XRP se quede por debajo del requisito de reserva. Puedes incluso destruir _todo_ tu XRP de esta forma.
|
||||
|
||||
Cuando tu cuenta posee menos XRP XRP que el requisito actual de reserva, no puedes enviar XRP a otros, o crear nuevos objetos que incremente el requisito de reserva de la cuenta. Aun así, la cuenta continua existiendo en el ledger y puedes enviar transacciones que no hagan esas cosas, siempre que tengas suficiente XRP para pagar el coste de transacción. Puedes volver a superar el requisito de reserva recibiendo suficiente XRP, o si el requisito de reserva decrece debajo de la cantidad que tiene.
|
||||
|
||||
**Consejo:** Si tu dirección está debajo del requisito de reserva, puedes enviar unas [transacciones OfferCreate][] para aadquirir más XRP y volver a superar el requisito de reeerva. Sin embargo, dado que no puedes crear una [entrada en el ledger Offer](../../references/protocol/ledger-data/ledger-entry-types/offer.md) cuando estás por debajo de la reserva, esta transacción puede consumir solo Offers que ya esté en el libro de ordenes.
|
||||
|
||||
|
||||
## Cambiar los requisitos de reserva
|
||||
|
||||
El XRP Ledger tiene un mecanismo para ajustar los requisitos de reserva. Estos ajustes pueden considerar, por ejemplo, cambios a largo plazo del valor de XRP, mejoras en la capacidad del hardware de los equipos convencionales, o una eficiencia incrementada en la implementación del software del servidor. Cualquier cambio tiene que ser aprobado por un proceso de consenso. Ver [Votación de fee](../consensus-protocol/fee-voting.md) para más información.
|
||||
|
||||
## Ver también
|
||||
|
||||
- [método account_objects][]
|
||||
- [Objeto AccountRoot][]
|
||||
- [Votación de Fee](../consensus-protocol/fee-voting.md)
|
||||
- [Pseudo-transacción SetFee][]
|
||||
- [Tutorial: Calcular y mostrar los requisitos de reserva (Python)](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#3-display-an-account)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
73
@i18n/es-ES/docs/concepts/accounts/tickets.md
Normal file
73
@i18n/es-ES/docs/concepts/accounts/tickets.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
html: tickets.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Envía transacciones en un orden no secuencial.
|
||||
labels:
|
||||
- Cuentas
|
||||
- Enviar transacciones
|
||||
---
|
||||
# Tickets
|
||||
|
||||
_(Añadido por la [enmienda TicketBatch][].)_
|
||||
|
||||
Un Ticket en el XRP Ledger es una forma de reservar un [número secuencia][Sequence Number] para una transacción que no se envía de inmediato. Los tickets permiten que transacciones sean enviadas fuera del orden de secuencia normal. Un caso de uso de esto es permitir [transacciones multi-signed](multi-signing.md) donde tomará un tiempo recolectar las firmas necesarias: mientras se recogen las firmas para una transacción que utiliza un Ticket, puedes enviar otras transacciones.
|
||||
|
||||
## Transfondo
|
||||
|
||||
Las [transacciones](../transactions/index.md) tienen números de secuencia para que una transacción determinada no pueda ejecutarse más que una vez. Los números de secuencia también se aseguran de que la transacción dada sea única: si envías la misma cantidad de dinero a la misma persona varias veces, el número de secuencia es un detalle que se garantiza que será diferente cada vez. Finalmente, los números de secuencia brindan una una forma felegante de ordenar las transacciones de forma consistente, incluso si algunas de ellas llegan desordenadas cuando se envían desordenadas a través de la red.
|
||||
|
||||
Sin embargo, hay situaciones donde los números de secuencia son demasiado limitantes. Por ejemplo:
|
||||
|
||||
- Dos o más usuarios comparten acceso a una cuenta, cada una con la habilidad de enviar transacciones independientemente. Si esos usuarios intentan enviar transacciones al mismo tiempo sin coordinarse primero, cada uno de ellos puede utilizar el mismo número de secuencia para diferentes transacciones, y sólo uno lo conseguirá.
|
||||
- Puede que quieras preparar y firmar una transacción por adelantado, luego guardarla en algún sitio seguro para que se pueda ejecutar en algún momento del futuro si ciertos eventos ocurren. Sin embargo, si quieres continuar usando la cuenta de forma normal mientras tanto, no sabes que número de secuencia apartar para la transacción. <!-- STYLE_OVERRIDE: will -->
|
||||
- Cuando [múltiples personas deben firmar una transacción](multi-signing.md) para hacerla válida, puede ser dificil planificar más de una transacción a la vez. Si numeras las transacciones con números de secuencia separados, no puedes enviar transacciones numeradas más tarde hasta que todo el mundo haya firmado las transacciones anteriores; pero si usas el mismo número de secuencia para cada transacción pendiente, solo una de ellas podrá ocurrir.
|
||||
|
||||
Los Tickets facilitan una solución para todos estos problemas apartando números de secuencia que se pueden uitlizar más adelante, fuera de su orden normal, pero aún así no más de una vez cada uno.
|
||||
|
||||
|
||||
## Los tickets son números de secuencia reservados
|
||||
|
||||
Un Ticket es un registro de que se ha apartado un número de secuencia para utilizar más adelante. Una cuenta envía primero una [transacción TicketCreate][] para apartar una o más números de secuencia como Tickets; esto deja un registro en los [datos de estado del ledger](../ledgers/index.md), en la forma de un [objeto Ticket][], para cada número de secuencia reservado.
|
||||
|
||||
Los Tickets están numerados usando los números de secuencia que han sido apartado para crearlos. Por ejemplo, si un número de secuencia de cuenta actual es 101 y has creado 3 Tickets, esos Tickets tienen los números de secuencia de Ticket 102, 103, y 104. Haciendo esto se incrementa el número de secuencia de la cuenta a 105.
|
||||
|
||||
[{% inline-svg file="/docs/img/ticket-creation.svg" /%}](/docs/img/ticket-creation.svg "Diagrama: Creación de tres tickets")
|
||||
|
||||
Más tarde, puedes enviar una transacción utilizando un Ticket específico en vez de un número de secuencia; haciendo eso eliminas el Ticket correspondiente de los datos de estado del ledger y no cambia el número de secuencia normal de tu cuenta. También puedes todavía enviar transacciones utilizando el números de secuencia normal sin utilizar Tickets. Puedes utilizar cualquiera de tus Tickets disponibles en cualquier orden en cualquier momento, pero cada Ticket puede utilizarse solo una vez.
|
||||
|
||||
[{% inline-svg file="/docs/img/ticket-usage.svg" /%}](/docs/img/ticket-usage.svg "Diagrama: Usando el ticket 103.")
|
||||
|
||||
Continuando con el ejemplo anterior, puedes enviar una transacción utilizando el número de secuencia 105 o cualquiera de los tres Tickets que has creado. Si envías una transacción utilizando el Ticket 103, esto eliminará el Ticket 103 del ledger. Tu próxima transacción despues de esa puede uitlizar el número de secuencia 105, el Ticket 102, o el Ticket 104.
|
||||
|
||||
**Atención:** Cada Ticket cuenta como un objeto separado para la [reserva de propietario](reserves.md), así que debes apartar 2 XRP por cada Ticket. (El XRP vuelve a estar disponible una vez que se haya utilizado el Ticket.) Este coste puede subir rápidamente si creas un grán número de Tickets a la vez.
|
||||
|
||||
Como con los números de secuencia, enviar una transacción consume el Ticket _si y solo si_ la transacción es confirmada por [consenso](../consensus-protocol/index.md). Sin embargo, las transacciones que fallan en hacer lo que intentaban pueden ser confirmadas por el consenso con los [códigos de resultado de clase`tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).
|
||||
|
||||
Para conocer qué Tickets tiene una cuenta disponibles, utiliza los [métodos account_objects][].
|
||||
|
||||
## Limitaciones
|
||||
|
||||
Cualquier cuenta puede crear y utilizar Tickets en cualquier tipo de transacciones. Sin embargo, puede haber algunas restricciones:
|
||||
|
||||
- Cada Ticket puede ser utilizado solo una vez. Es posible tener múltiples transacciones diferentes candidatas que podrían usar el mismo Ticket Secuencia, pero solo uno de esos candidatos será validado por el consenso.
|
||||
- Una cuenta no puede tener más de 250 Tickets en el ledger a la vez. No puedes crear más de 250 Tickets a la vez, tampoco.
|
||||
- _Puedes_ usar un Ticket para crear más Tickets. Si lo haces, el Ticket utilizado no cuenta para el número total de Tickets que puedes tener a la vez.
|
||||
- Cada Ticket cuenta para la [reserva de propietario](reserves.md), por lo que debes apartar 2 XRP por cada Ticket que no has usado todavía. El XRP vuelve a estar disponible para ti despues de utilizar el Ticket.
|
||||
- Dentro de un ledger individual, las transacciones que usan Tickets se ejecutan después que otras transacciones desde el mismo remitente. Si una cuenta tiene múltiples transacciones utilizando Tickets en la misma versión del ledger, esos Tickets se ejecutan en orden desde el Ticket con la secuencia más baja hasta la más alta. (Para más información, ver la documentación del [orden canónico](../consensus-protocol/consensus-structure.md#calculate-and-share-validations) del consenso.)
|
||||
- Para "cancelar" un Ticket, usa el Ticket para [realizar una operación no operativa](../transactions/finality-of-results/canceling-a-transaction.md) [transacción AccountSet][]. Esto elimina el Ticket y tu no tienes que cumplir con los requisitos de reserva.
|
||||
|
||||
## Ver también
|
||||
|
||||
|
||||
- **Conceptos:**
|
||||
- [Multi-Signing](multi-signing.md)
|
||||
- **Tutoriales:**
|
||||
- [Usar Tickets](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
|
||||
- **Referencias:**
|
||||
- [Transacción TicketCreate][]
|
||||
- [Campos comunes de una transacción](../../references/protocol/transactions/common-fields.md)
|
||||
- [Objeto Ticket](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
|
||||
- [Método account_objects ][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.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. <!-- STYLE_OVERRIDE: obviously -->
|
||||
|
||||
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.. <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
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" /%}
|
||||
@@ -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).
|
||||
@@ -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. |
|
||||
|
||||
<!-- SPELLING_IGNORE: bft, liveness -->
|
||||
@@ -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`**.<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
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 <a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>. 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. <a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>.
|
||||
|
||||
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 <a href="#footnote_4" id="from_footnote_4"><sup>4</sup></a> 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)_.<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a> 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 <a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a>. <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
[{% 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).<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
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 <a href="#footnote_7" id="from_footnote_7"><sup>7</sup></a>. 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 <a href="#footnote_8" id="from_footnote_8"><sup>8</sup></a>. 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 <a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>, 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 <a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>.
|
||||
- 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
|
||||
|
||||
<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_2" id="footnote_2"><sup>2</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_3" id="footnote_3"><sup>3</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_4" id="footnote_4"><sup>4</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_5" id="footnote_5"><sup>5</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – 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).
|
||||
|
||||
<a href="#from_footnote_7" id="footnote_7"><sup>7</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_8" id="footnote_8"><sup>8</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – 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.
|
||||
|
||||
<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – 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" /%}
|
||||
67
@i18n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
Normal file
67
@i18n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
Normal file
@@ -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` | 2<sup>64</sup> | (Más XRP del que nunca ha existido.) |
|
||||
| `account_reserve` | 2<sup>32</sup> drops | Aproximadamente 4294 XRP |
|
||||
| `owner_reserve` | 2<sup>32</sup> 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" /%}
|
||||
72
@i18n/es-ES/docs/concepts/consensus-protocol/index.md
Normal file
72
@i18n/es-ES/docs/concepts/consensus-protocol/index.md
Normal file
@@ -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. <a id="footnote-1"></a> 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. <a id="footnote-2"></a> 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. <!-- SPELLING_IGNORE: utxos -->
|
||||
|
||||
3. <a id="footnote-3"></a> 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.
|
||||
@@ -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" /%}
|
||||
178
@i18n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
Normal file
178
@i18n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
Normal file
@@ -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 = V<sub>a</sub> ÷ 256
|
||||
|
||||
V<sub>a</sub> 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" /%}
|
||||
35
@i18n/es-ES/docs/concepts/ledgers/index.md
Normal file
35
@i18n/es-ES/docs/concepts/ledgers/index.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
html: ledgers.html
|
||||
parent: concepts.html
|
||||
seo:
|
||||
description: Los libros contables o ledgers son la estructura de datos que contiene datos en la red compartida de XRP Ledger. Una cadena de ledgers registra el historial de transacciones y cambios de estado.
|
||||
labels:
|
||||
- Blockchain
|
||||
- Retención de datos
|
||||
---
|
||||
# Ledgers
|
||||
|
||||
El XRP Ledger es un libro contable global compartido que está abierto para todos. Participantes individuales pueden confiar en la la integridad del ledger sin tener que confiar en una única institución para manejarlo. El protocolo XRP Ledger logra esto mediante la gestión de la base de datos de contabilidad que solo puede ser actualizada de acuerdo a unas reglas específicas. Cada servidor en la reed peer-to-peer guarda una copia completa de la base de datos del ledger o libro contable, y la red distribuye transacciones candidatas, las cuales se incluyen en bloques de acuerdo al [proceso de consenso](../consensus-protocol/index.md).
|
||||
|
||||
[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg "Diagrama: Cada ledger es el resultado de aplicar transacciones a la anterior versión del ledger.")
|
||||
|
||||
El ledger global compartido consiste en una serie de bloques, llamadas versiones del ledger o simplemente _ledgers_. Cada versión del ledger tiene un índice o [Ledger Index][] el cual identifica el orden correcto de los ledgers. Cada ledger cerrado es permanente y también tiene un único valor hash que lo identifica.
|
||||
|
||||
En cualquier momento, cada servidor XRP Ledger tiene un ledger _abierto_ en progreso, un número de ledgers _cerrados_ pendientes, y un histórico de ledgers _validados_ que son inmutables.
|
||||
|
||||
Una versión del ledger consta de varias partes:
|
||||
|
||||
[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "Diagrama: Un ledger tiene transacciones, un arbol de estado, y una cabecera con la hora de cierre y la información de validación")
|
||||
|
||||
* Una **cabecera** - El índice del ledger o [Ledger Index][], hashes de sus otros contenidos, y otros metadatos.
|
||||
* Un **arbol de transacciones** - Las [transacciones](../../references/protocol/transactions/index.md) que se aplicaron al ledger anterior para hacer este.
|
||||
* Un **arbol de estado** - Todos los datos en el ledger, como [entradas del ledger](../../references/protocol/ledger-data/ledger-entry-types/index.md): balances, configuraciones, y demás.
|
||||
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- 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" /%}
|
||||
41
@i18n/es-ES/docs/concepts/ledgers/ledger-close-times.md
Normal file
41
@i18n/es-ES/docs/concepts/ledgers/ledger-close-times.md
Normal file
@@ -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.
|
||||
70
@i18n/es-ES/docs/concepts/ledgers/ledger-structure.md
Normal file
70
@i18n/es-ES/docs/concepts/ledgers/ledger-structure.md
Normal file
@@ -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.
|
||||
@@ -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.
|
||||
88
@i18n/es-ES/docs/concepts/networks-and-servers/amendments.md
Normal file
88
@i18n/es-ES/docs/concepts/networks-and-servers/amendments.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
html: amendments.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Las enmiendas representan nuevas funcionalidades u otros cambios para el procesamiento de transacciones. Los validadores se coordinan a través del consenso para aplicar estas mejoras al XRP Ledger de manera ordenada.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Enmiendas
|
||||
|
||||
Las enmiendas representan nuevas funcionalidades u otros cambios en el procesamiento de transacciones.
|
||||
|
||||
El sistema de enmiendas utiliza el proceso de consenso para aprobar cualquier cambio que afecte el procesamiento de transacciones en el XRP Ledger. Los cambios en el proceso de transacción completamente funcionales se introducen como enmiendas; luego, los validadores votan sobre estos cambios. Si una enmienda recibe más del 80% de apoyo durante dos semanas, la enmienda se aprueba y el cambio se aplica permanentemente a todas las versiones de ledgers subsiguientes. Deshabilitar una enmienda aprobada requiere una nueva enmienda para hacerlo.
|
||||
|
||||
**Nota:** Las correcciones de errores que cambian los procesos de transacción también requieren enmiendas.
|
||||
|
||||
<!-- TODO: Move this to an amendment tutorial.
|
||||
Every amendment has a unique identifying hex value and a short name. The short name is for readability only; servers can use different names to describe the same amendement ID, and the names aren't guaranteed to be unique. The amendment ID should be the SHA-512Half hash of the amendment's short name.
|
||||
-->
|
||||
|
||||
## Proceso de enmienda
|
||||
|
||||
El apartado [Código de contribución al XRP Ledger](/resources/contribute-code/index.md) describe el flujo de trabajo para desarrollar una enmienda desde una idea hasta su activación en el XRP Ledger.
|
||||
|
||||
Después de que el código para una enmienda se incluye en una versión de software o software release, el proceso para habilitarlo ocurre dentro de la red del XRP Ledger, que verifica el estado de las enmiendas en cada _flag_ ledger (generalmente cada 15 minutos).
|
||||
|
||||
Cada 256º ledger se llama **flag** ledger. El flag ledger no tiene contenidos especiales, pero el proceso de enmienda ocurre alrededor suyo.
|
||||
|
||||
1. **Flag Ledger -1:** Cuando los validadores `rippled` envían mensajes de validación, también envían sus votos sobre enmiendas.
|
||||
2. **Flag Ledger:** Los servidores interpretan los votos de los validadores confiables.
|
||||
3. **Flag Ledger +1:** Los servidores insertan la pseudo transacción `EnableAmendment` y marcan dependiendo de lo que piensan que ha pasado:
|
||||
* El flag (o marca) `tfGotMajority` significa que la enmienda tiene más del 80% del apoyo.
|
||||
* El flag (o marca) `tfLostMajority` significa que el apoyo de la enmienda ha descendido al 80% o menos.
|
||||
* Que no haya flag (o marca) significa que la enmienda está activada.
|
||||
|
||||
**Nota:** Es posible para una enmienda perder el 80% del apoyo en el mismo ledger en el que alcanza el periodo de dos semanas para ser activada. En esos casos, una pseudo-transaccion `EnableAmendment` es añadida en ambos escenarios, pero la enmienda es activada finalmente.
|
||||
|
||||
4. **Flag Ledger +2:** Enmiendas activadas aplican a transacciones en este ledger en adelante.
|
||||
|
||||
|
||||
## Votación de enmienda
|
||||
|
||||
Cada versión de `rippled` es compilada con una lista de [enmiendas conocidas](/resources/known-amendments.md) y el código para implementar esas enmiendas. Los operadores de los validadores `rippled` configuran sus servidores para votar en cada enmienda y cambiarlo en cada momento. Si un operador no elige un voto, el servidor por defecto tiene un voto definido en el códido fuente.
|
||||
|
||||
**Nota:** El voto por defecto cambia entre las publicaciones del software. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Actualizado en: rippled 1.8.1{% /badge %}
|
||||
|
||||
Las enmiendas deben mantener dos semanas el apoyo de más del 80% de los validadores confiables para activarse. Si el apoyo baja por debajo del 80%, la enmienda es temporalmente rechazada , y el periodo de dos semanas se reinicia. Las enmiendas pueden ganar y perder una mayoría cualquier cantidad de veces antes de que se habiliten permanentemente.
|
||||
|
||||
Las enmiendas que hayan tenido su código fuente removido sin haberse activado on consideradas **vetadas** por la red.
|
||||
|
||||
|
||||
## Servidores bloqueados por enmienda
|
||||
<a id="amendment-blocked"></a>
|
||||
|
||||
El bloqueo por enmienda es una característica de seguridad para proteger la precisión de los datos del XRP Ledger. Cuando una enmienda se activa, los servidores ejecutando versiones anteriores de `rippled` sin el código fuente de la enmienda ya no consiguen entender las reglas de la red. En vez de adivinar y malinterpretar los datos del ledger, estos servidores se convierten en servidores **bloqueados por enmienda** y no pueden:
|
||||
|
||||
* Determinar la validez de un ledger.
|
||||
* Enviar o procesar transacciones.
|
||||
* Participar en el proceso de consenso.
|
||||
* Votar sobre futuras enmiendas.
|
||||
|
||||
La configuración de votación de un servidor `rippled` no tiene impacto en convertirse en un servidor bloqueado por enmienda. Un servidor `rippled` siempre sigue las enmiendas activadas por el resto de la red, por lo que los bloqueos solo se basan en tener el código para entender los cambios de reglas. Esto significa que tu también te puedes convertir en alguien bloqueado por enmienda si conectas tu servidor a una red paralela con enmiendas activadas. Por ejemplo, La Devnet de XRP normalmente tiene enmiendas experimentales activadas. Si estás utilizando la última publicación o release en producción, tu servidor no tendrá ese código de esas enmiendas experimentales.
|
||||
|
||||
Puedes debloquear servidores bloqueados por enmienda actualizando a la última versión de `rippled`.
|
||||
|
||||
### Servidores Clio bloqueados por enmienda
|
||||
|
||||
Los servidores Clio pueden bloquearse por enmienda si se encuentran un tipo de campo desconocido mientras cargan los datos del ledger. Esto ocurre si el campo es más nuevo que la dependencia de `libxrpl` usada cuando se construye Clio. Para desbloquear tu servidor Clio, actualiza a la última release de Clio que se publicó con un `libxrpl` compatible.
|
||||
|
||||
## Retiro de enmiendas
|
||||
|
||||
Cuando las enmiendas son activadas, el código fuente de comportamientos previos a la enmienda permanece en `rippled`. Mientras hay casos de uso para mantener el código antiguo, como la reconstrucción de resultados de los ledgers para verificación, el seguimiento de enmiendas y código heredado agrega complejidad con el tiempo.
|
||||
|
||||
El [Estándar 11d de XRP Ledger](https://github.com/XRPLF/XRPL-Standards/discussions/19) define un proceso para retirar enmiendas antiguas y código asociado previo a la enmienda. Después de que una enmienda haya sido activada en Mainnet por dos años, puede ser retirado. Retirar una enmienda la convierte en parte del protocolo central incondicionalmente; ya no se sigue ni se trata como una enmienda, y todo el código anterior a la enmienda es eliminado.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- **Tutoriales:**
|
||||
- [Ejecutar rippled como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
|
||||
- [Configurar votación de enmiendas](../../infrastructure/configuration/configure-amendment-voting.md)
|
||||
- [Contribuir al código del XRP Ledger](/resources/contribute-code/index.md)
|
||||
- **Referencias:**
|
||||
- [Enmiendas conocidas](/resources/known-amendments.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
29
@i18n/es-ES/docs/concepts/networks-and-servers/clustering.md
Normal file
29
@i18n/es-ES/docs/concepts/networks-and-servers/clustering.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
html: clustering.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Ejecuta servidores rippled en un cluster para compartir la carga criptográfica entre ellos.
|
||||
labels:
|
||||
- Servidor principal
|
||||
---
|
||||
# Clustering
|
||||
|
||||
Si estás ejecutando varios servidores `rippled` en un único datacenter, puedes configurar esos servidores dentro de un cluster para maximizar la eficiencia. Ejecutar tus servidores `rippled` en un cluster proporciona los siguientes beneficios:
|
||||
|
||||
- Los servidores `rippled` clusterizados comparten el trabajo critográfico. Si un servidor ha verificado la autenticidad del mensaje, los otros servidores en el cluster confian en él y no lo vuelven a verificar.
|
||||
- Los servidores clusterizados comparten información sobre pares y clientes API que están comportandose mal o abusando de la red. Esto dificulta atacar todos los servidores del cluster a la vez.
|
||||
- Los servidores clusterizados siempre propagan las transacciones a través del cluster, incluso si la transacción no cumple con el coste de transacción actual basada en la carga en alguno de ellos.
|
||||
|
||||
Si estás ejecutando un validador como un [par privado](peer-protocol.md#pares-privados), Ripple recomienda utilizar un cluster de servidores `rippled` como servidores proxy.
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Tutoriales:**
|
||||
- [Cluster de servidores `rippled`](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
|
||||
- [Ejecutar rippled como validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
|
||||
- **Referencias:**
|
||||
- [método peers][]
|
||||
- [método connect][]
|
||||
- [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
41
@i18n/es-ES/docs/concepts/networks-and-servers/index.md
Normal file
41
@i18n/es-ES/docs/concepts/networks-and-servers/index.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
html: networks-and-servers.html
|
||||
parent: concepts.html
|
||||
seo:
|
||||
description: rippled es el servidor peer-to-peer principal que maneja el XRP Ledger.
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# Redes y servidores
|
||||
|
||||
Hay dos tipos principales de software de servidores que alimentan el XRP Ledger:
|
||||
|
||||
- El servidor principal, `rippled`, ejecuta la red peer-to-peer la cual procesa transacciones y alcanza un consenso en sus resultados.
|
||||
- El servidor API, [Clio](the-clio-server.md), proporciona potentes interfaces para obtener o consultar datos desde el ledger.
|
||||
|
||||
Cualquiera puede ejecutar instancias de uno o ambos de estos tipos de servidores basado en sus necesidades.
|
||||
|
||||
## Razones por las que ejecutar tu propio servidor
|
||||
|
||||
Para casos de uso más livianos y servidores individuales, puedes depender de [servidores públicos][]. Sin embargo, cuanto más serio sea tu uso del XRP Ledger, más importante será tener tu propia infraestructura.
|
||||
|
||||
Hay multitud de razones por las que quieres ejecutar tus propios servidores, pero la mayoría de ellas se pueden resumir en: puedes confiar en tu propio servidor, tienes control sobre la carga de trabajo, y no estás a merced de otros que decidan cuando y cómo puedes acceder. Por supuesto, debes tener tener unas buenas prácticas respecto a la seguridad de la red para proteger tu servidor de hackers maliciosos.
|
||||
|
||||
Necesitas confiar en el servidor que utilizas. Si te conectas a un servidor malicioso, hay muchas maneras en las que se pueda aprovechar de ti o hacerte perder dinero. Por ejemplo:
|
||||
|
||||
* Un servidor malicioso podría informar que has sido pagado cuando no se ha hecho el pago.
|
||||
* Podría selectivamente mostrar u ocultar los caminos (o paths) de pago y las foertas de intercambio de divisas para garantizar su propio beneficio mientras no te ofrece la mejor oferta.
|
||||
* Si le enviaste la clave secreta de tu dirección, esto podría generar transacciones arbitrarias en tu nombre e incluso transferir o destruir todo el dinero que la dirección posee.
|
||||
|
||||
Adicionalmente, ejecutar tu propio servidor te da [acceso de administrador](../../tutorials/http-websocket-apis/build-apps/get-started.md#admin-access), lo que te permite ejecutar comandos exclusivos de administrador y de carga intensa. Si utilizas un servidor compartido, debes preocuparte por los otros usuarios del mismo servidor compitiendo contra ti por el poder de computación del servidor. Muchos de los comandos en el API WebSocket puede poner mucha presión sobre el servidor, por lo que el servidor tiene la opción de reducir sus respuestas cuando lo necesite. Si compartes un servidor con otros, puede que no siempre consigas los mejores resultados posibles.
|
||||
|
||||
Finalmente, si ejecutas un servidor de validación, puedes utilizar un servidor común como proxy a la red pública mientras mantienes tu servidor de vaalidación en una red privada la cual es solo accesible desde el mundo exterior desde tu servidor común. Esto hace más difícil comprometer la integridad de tu servidor de validación.
|
||||
|
||||
## Características y temas del servidor
|
||||
|
||||
<!-- provided by the auto-generated table of children -->
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
html: ledger-history.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Los servidores rippled almacenan una cantidad variable de transacciones e historial del estado localmente.
|
||||
labels:
|
||||
- Retención de datos
|
||||
- Blockchain
|
||||
- Servidor principal
|
||||
---
|
||||
# Histórico del ledger
|
||||
|
||||
El [proceso de consenso](../consensus-protocol/index.md) crea una cadena de [versiones de ledgers validados](../ledgers/index.md), cada uno derivado del anterior aplicando un conjunto de [transacciones](../transactions/index.md). Cada [servidor `rippled`](index.md) almacena versiones de ledgers y el historial de transacciones locálmente. La cantidad de histórico de transacciones que un servidor almacena depende de cuanto tiempo ese servidor ha estado online y cuanto histórico está configurado para recuperar y mantener.
|
||||
|
||||
Los servidores en la red peer-to-peer XRP Ledger comparten transacciones y otros datos entre sí como parte del proceso de consenso. Cada servidor construye de forma independiente una nueva versión del ledger y compara los resultados con sus validadores de confianza para asegurar la consistencia. (Si un consenso de validadores de confianza no está de acuerdo con los resultados de un servidor, ese servidor recupera los datos necesarios de sus pares para lograr consistencia.) Los servidores pueden descargar datos más antiguos de sus pares para completar huecos en su historial disponible. La estructura del ledger utiliza [hashes](../../references/protocol/data-types/basic-data-types.md#hashes) criptográficos de los datos para que cualquier servidor pueda verificar la integridad y consistencia de los datos.
|
||||
|
||||
## Bases de datos
|
||||
|
||||
Los servidores mantienen datos del estado del ledger y transacciones en un almacén de clave-valor llamada almacén del ledger o _ledger store_. Además, `rippled` mantiene algunos archivos de base de datos SQLite para un acceso más flexible a cosas como el historial de transacciones y para rastrear ciertos cambios de configuración.
|
||||
|
||||
Normalmente, es seguro eliminar todos los archivos de base de datos de un servidor `rippled` cuando ese servidor no está en funcionamiento. (Es posible que quieras hacer esto, por ejemplo, si cambias la configuración de almacenamiento del servidor o si estás cambiando de una red de prueba a la red de producción).
|
||||
|
||||
## Historial disponible
|
||||
|
||||
Por diseño, todos los datos y transacciones en el XRP Ledger son públicos y cualquiera puede buscar o consultar cualquier cosa. Sin embargo, tu servidor solo puede buscar datos que tenga disponibles localmente. Si intentas buscar una versión del ledger o una transacción que tu servidor no tenga disponible, tu servidor responderá que no puede encontrar esos datos. Otros servidores que tengan el historial necesario pueden responder con éxito a la misma consulta. Si tienes un negocio que utiliza datos del XRP Ledger, debes tener cuidado de cuánto historial tiene disponible tu servidor.
|
||||
|
||||
El [método server_info][] reporta cuántas versiones del ledger tiene disponibles en el campo `complete_ledgers`.
|
||||
|
||||
## Recuperar el histórico
|
||||
|
||||
Cuando un servidor del XRP Ledger se inicia, su primera prioridad es obtener una copia completa del último ledger validado. A partir de ahí, se mantiene al día con los avances en el progreso del ledger. El servidor completa cualquier agujero en su historial del ledger que ocurra después de sincronizar y puede rellenar el historial desde antes de que se sincronizara. (Los huecos en el historial del ledger pueden ocurrir si un servidor temporalmente se vuelve demasiado ocupado para mantenerse al día con la red, pierde su conexión de red u experimenta otros problemas temporales).Cuando descarga el historial del ledger, el servidor solicita los datos faltantes a sus [servidores pares](peer-protocol.md), y verifica la integridad de los datos utilizando [hashes][Hash] criptográficos.
|
||||
|
||||
Rellenar el histórico es uno de las prioridades más bajas del servidor, por lo que puede llevar mucho tiempo completar el historíal faltante, especialmente si el servidor está ocupado o si las especificaciones del hardware y la red no son lo suficientemente buenas. Para recomendaciones en especificaciones de hardware, ver [Planificación de capacidad](../../infrastructure/installation/capacity-planning.md). Completar el histórico también requiere que al menos uno de los pares directos del servidor tenga el histórico en cuestión. Para más información de cómo administrar las conexiones peer-to-peer de tu servidor, consulta [Configurar Peering](../../infrastructure/configuration/peering/index.md).
|
||||
|
||||
El XRP Ledger identifica datos (en varios niveles diferentes) mediante un hash único de sus contenidos. Los datos de estado del XRP Ledger contienen un resumen breve del histórico del ledger, en forma de [tipos de objeto LedgerHashes](../../references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md). Los serivodres usan los objetos LedgerHashes para conocer qué versiones del ledger hay que buscar, y confirmar que los datos del ledger que recibe son correctos y completos.
|
||||
|
||||
|
||||
<a id="with-advisory-deletion"></a><!-- old anchor to this area -->
|
||||
### Rellenar
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}Actualizado en: rippled 1.6.0{% /badge %}
|
||||
|
||||
La cantidad de histórico que un servidor intenta descargar depende de su configuración. El servidor automáticamente intenta rellenar los huecos descargando el histórico hasta **el ledger más antiguo que está actualmente disponible**. Pues utilizar el campo `[ledger_history]` para hacer al servidor rellenar el histórico más allá de ese punto. Sin embargo, el servidor nunca descarga ledgers que estuviesen programados para su [eliminación](../../infrastructure/configuration/data-retention/online-deletion.md).
|
||||
|
||||
El campo `[ledger_history]` define el número mínimo de ledgers que se acumulan antes del ledger actual validado. Utiliza el valor especial `full` para descargar el [histórico completo](#full-history) de la red. Si especificas un número de ledgers, debe ser igual o mayor que el campo `online_deletion`; no puedes utilizar `[ledger_history]` para hacer al servidor descargar _menos_ histórico. Para reducir la cantidad de histórico que un servidor almacena, cambia el ajuste [online deletion](../../infrastructure/configuration/data-retention/online-deletion.md). <!-- STYLE_OVERRIDE: a number of -->
|
||||
|
||||
|
||||
|
||||
## Histórico completo
|
||||
|
||||
Algunos servidores en la red XRP Ledger están configurados como servidores "full-history". Estos servidores, los cuales requieren sifnificativamente más espacio de disco que otros servidores de seguimiento, almacenan todo el histórico disponible XRP Ledger y **no usan la opción online deletion**.
|
||||
|
||||
La XRP Ledger Foundation proporciona acceso a un cojunto de servidores full history operados por miembros de la comunidad (ver [xrplcluster.com](https://xrplcluster.com) para más detalles).
|
||||
Ripple también proporciona un conjunto de servidores full-history públicos como un servicio público en `s2.ripple.com`. <!-- SPELLING_IGNORE: xrplcluster -->
|
||||
|
||||
Los proveedores de servidores Full History se reservan el derecho de bloquear acceso a aquellos que abusen de los rescursos, o generen una carga desproporcionada a los sistemas.
|
||||
|
||||
**Consejo:** A diferencia de algunas redes de criptomonedas, los servidores en el XRP Ledger no necesitan un full history para conocer el estado actual y mantenerse a día con las transacciones actuales.
|
||||
|
||||
Para instrucciones de cómo configurar un servidor full history, consultar [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
|
||||
|
||||
## Fragmentación del historial
|
||||
|
||||
Una alternativa para almacenar todo el histórico completo del XRP Ledger en una única máquina cara es configurar muchos servidores para que cada uno almacene una parte del histórico completo del ledger. La función [Fragmentación del histórico](../../infrastructure/configuration/data-retention/history-sharding.md) hace esto posible, almacenando rangos del histórico del ledger en áreas de almacenamiento separadas llamadas almacenes de fragmentación o _shard store_. Cuando un servidor par solicita datos específicos (como se describe en [fetching history](#recuperar-el-histórico) arriba), un servidor puede responder usando datos de su ledger store o shard store.
|
||||
|
||||
Online deletion **no** borra desde un shard store. Sin embargo, si configuras online deletion para mantener al menos 32768 versiones de ledger en el ledger store de tu servidor, tu servidor puede copiar shards completos desde el ledger store al shard store antes de borrarlos automáticamente del ledger store.
|
||||
|
||||
Para más información, ver [Configurar History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md).
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Ledgers](../ledgers/index.md)
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- **Tutoriales:**
|
||||
- [Configurar `rippled`](../../infrastructure/configuration/index.md)
|
||||
- [Configurar Online Deletion](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
|
||||
- [Configurar Advisory Deletion](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
|
||||
- [Configurar History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md)
|
||||
- [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md)
|
||||
- **Referencias:**
|
||||
- [método ledger][]
|
||||
- [método server_info][]
|
||||
- [método ledger_request][]
|
||||
- [método can_delete][]
|
||||
- [método ledger_cleaner][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
html: parallel-networks.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Entender cómo las redes de prueba (test) y cadenas ledger alternativas se relacionan con el XRP Ledger en producción.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Redes paralelas
|
||||
|
||||
Existe una red peer-to-peer en producción del XRP Ledger, y todos los negocios que tienen lugar en el XRP Ledger ocurren dentro de la red de producción: la Mainnet.
|
||||
|
||||
Para ayudar a miembros de la comunidad del XRP Ledger a interactuar con la tecnología sin afectar nada a la Mainnet, hay redes alternativas, o altnets. Aquí hay un desglose de algunas altnets públicas:
|
||||
|
||||
| Red | Cadencia de actualización | Descripción |
|
||||
|:--------|:----------------|:-------------------------------------------------|
|
||||
| Mainnet | Lanzamientos estables | _El_ [XRP Ledger](/about/), un libro contable criptográfico descentralizado impulsado por una red de servidores peer-to-peer y el hogar de [XRP](../../introduction/what-is-xrp.md). |
|
||||
| Testnet | Lanzamientos estables | Una red de "universo alternativo" que actua como un campo de pruebas para el software construido en el XRP Ledger, sin impactar a los usuarios del XRP Ledger de producción y sin arriesgar dinero real. El [estado de enmienda](/resources/known-amendments.md) de Testnet está destinado a reflejar de cerca el de la Mainnet, aunque pueden ocurrir ligeras variaciones en el tiempo debido a la naturaleza impredecible de los sistemas descentralizados. |
|
||||
| Devnet | Lanzamientos Beta | Una vista previa de las próximas atracciones, donde cambios inestables en el software principal de XRP Ledger se pueden probar. Los desarrolladores pueden utilizar esta altnet para interactuar y aprender sobre funcionalidades nuevas planficiadas para el XRP Ledger y enmiendas que no están habilitadas en la Mainnet. |
|
||||
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Servidor Hooks](https://github.com/XRPL-Labs/xrpld-hooks) | Una vista previa de la funcionalidad de smart contract en la cadena utilizando [hooks](https://xrpl-hooks.readme.io/). |
|
||||
| Sidechain-Devnet | Lanzamientos Beta | Una sidechain para probar funcionalidades en puentes cross-chain. Devnet se trata como la cadena de bloqueo y esta sidechain es la cadena de emisión.<br>Soporte a la librería:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**Nota**: También puedes usar la herramienta de línea de comandos [`xbridge-cli`](https://github.com/XRPLF/xbridge-cli) para configurar un puente entre cadenas en tu máquina local. |
|
||||
|
||||
Cada altnet tiene su propia distribución separada de XRP de prueba, que se [regala gratis](/resources/dev-tools/xrp-faucets) a partes interesadas en experimentar con el XRP Ledger y desarrollar aplicaciones e integraciones. El XRP test no tiene valor en el mundo real y se pierde cuando la red se reinicia.
|
||||
|
||||
**Atención:** A diferencia de la Mainnet del XRP Ledger, las redes de prueba suelen ser _centralizadas_ y no hay garantías sobre la estabilidad y disponibilidad de estas redes. Han sido y siguen siendo utilizadas para probar diversas propiedades de la configuración del servidor, la topología de la red y el rendimiento de la red.
|
||||
|
||||
|
||||
## Redes paralelas y consenso
|
||||
|
||||
El factor principal en determinar qué red sigue un servidor es su UNL configurado-la lista de validadores en los que confía para no colisionar. Cada servidor utiliza su UNL configurada para saber qué ledger aceptar como la verdad. Cuando diferentes grupos de consenso de instancias de `rippled` solo confían en otros miembros del mismo grupo, cada grupo continúa como una red paralela. Incluso si equipos maliciosos o malintencionados se conectan a ambas redes, el proceso de consenso evita la confusión siempre y cuando los miembros de cada red no estén configurados para confiar en miembros de otra red en exceso de su configuración de cuórum.
|
||||
|
||||
Ripple ejecuta los servidores principales en la Testnet y Devnet; también puedes [conectar tu propio servidor `rippled` para estas redes](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md). La Testnet y Devnet no utilizan conjuntos de validadores diversos y resistentes a la censura. Esto hace posible que Ripple reinicie la Testnet o Devnet en cualquier momento.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Herramientas:**
|
||||
- [XRP Testnet Faucet](/resources/dev-tools/xrp-faucets)
|
||||
- **Conceptos:**
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- [Enmiendas](amendments.md)
|
||||
- **Tutoriales:**
|
||||
- [Conectar tu `rippled` en laTestnet XRP](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
|
||||
- [Usar rippled en modo Stand-Alone](../../infrastructure/testing-and-auditing/index.md)
|
||||
- **Referencias:**
|
||||
- [método server_info][]
|
||||
- [método consensus_info][]
|
||||
- [método validator_list_sites][]
|
||||
- [método validators][]
|
||||
- [Opciones modo Daemon](../../infrastructure/commandline-usage.md#daemon-mode-options)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
174
@i18n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
Normal file
174
@i18n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
Normal file
@@ -0,0 +1,174 @@
|
||||
---
|
||||
html: peer-protocol.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: El protocolo de pares especifica el lenguaje en el que los servidores rippled hablan entre sí.
|
||||
labels:
|
||||
- Servidor principal
|
||||
- Blockchain
|
||||
---
|
||||
# Protocolo de pares
|
||||
|
||||
Los servidores en el XRP Ledger se comunican entre sí utilizando el protocolo de pares del XRP Ledger.
|
||||
|
||||
El protocolo de pares es el modo principal de comunicación entre servidores en el XRP Ledger. Toda la información sobre el comportamiento, progreso, y conectividad en el XRP Ledger pasa a través del protocolo de pares. Ejemplos de comunicación peer-to-peer incluyen todos los siguientes:
|
||||
|
||||
- Solicitar una conexión a otros servidores en la red peer-to-peer, o anunciar que hay huecos de conexión disponibles.
|
||||
- Compartir transacciones candidatas con el resto de la red.
|
||||
- Solicitar datos de ledger de ledgers históricos, o proporcionar esos datos.
|
||||
- Proponer una conjunto de transacciones para el consenso, o compartir el resultado calculado de aplicar el conjunto de transacciones de consenso.
|
||||
|
||||
Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando HTTPS y solicita una [actualización HTTP](https://tools.ietf.org/html/rfc7230#section-6.7) para cambiar al protocolo `XRPL/2.0` (anteriormente `RTXP/1.2`). (Para más información, consultar el artículo [Red de superposición](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) en el [repositorio `rippled`](https://github.com/ripple/rippled).)
|
||||
|
||||
## Descubrimiento de pares
|
||||
|
||||
El XRP Ledger utiliza el protocolo del "chismorreo" para ayudar a servidores a encontrar otros servidores para conectarse en la red XRP Ledger. Cuando un servidor se inicia, se reconecta a cualquier otro par al que se haya conectado anteriormente. Como alternativa, utiliza los [hubs públicos hardcodeados](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). Después de que un servidor se conecte correctamente a un par, le pregunta a ese par por información de contacto (generalmente, dirección IP y puerto) de otros servidores XRP Ledger que también pueden estar buscando pares. El servidor puede conectarse entonces a esos servidores, y preguntarles por información de contacto de todavía más servidores a los que conectarse. A través de este proceso, el servior hace suficientes conexiones de pares para que pueda permanecer contectado con el resto de la red incluso si pierde la conexión con cualquier par en particular.
|
||||
|
||||
Normalmente, un servidor necesita conectarse a un hub público solo una vez, durante un corto período de tiempo, para encontrar otros pares. Después de hacerlo, el servidor puede o no permanecer conectado al hub, dependiendo de la estabilidad de su conexión de red, de lo ocupado que esté el hub y de cuántos otros pares de alta calidad encuentre el servidor. El servidor guarda las direcciones de estos otros pares para poder intentar reconectarse directamente a esos pares más tarde, después de una interrupción en la red o un reinicio.
|
||||
|
||||
El [método peers][] muestra una lista de pares a los que tu servidor está actualmente conectado.
|
||||
|
||||
Para ciertos servidores de alto valor (tan importantes como [validadores](rippled-server-modes.md#modos-de-servidor-rippled)) puedes preferir no conectarte a pares no confiables a través del proceso de descubrimiento de pares. En este caso, puedes configurar tu servidor para usar solo [pares privados](#pares-privados).
|
||||
|
||||
|
||||
## Puerto del protocolo de pares
|
||||
|
||||
Para participar en el XRP Ledger, los servidores `rippled` conectan con pares arbitrarios utilizando el protocolo de pares. (Todos los pares son como no confiables, a no ser que sean de tipo [clusterizado](clustering.md) con el servidor actual.)
|
||||
|
||||
Idealmente, el servidor debería poder enviar _y_ recibir conexiones en el puerto de pares. Debes [redireccionar el puerto utilizado por el protocolo de pares a través de tu firewall](../../infrastructure/configuration/peering/forward-ports-for-peering.md) para el servidor `rippled`.
|
||||
|
||||
IANA [ha asignado el puerto **2459**](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2459) para el protocolo de pares del XRP Ledger, pero para la compatibilidad con sistemas antiguos, el [fichero de configuración por defecto de `rippled`](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg) escucha las conexiones entrantes de pares con el **port 51235** en todas las interfaces de la red. Si ejecutas un servidor, puedes configurar qué puerto(s) escucha tu servidor utilizando el fichero `rippled.cfg`.
|
||||
|
||||
Ejemplo:
|
||||
|
||||
```
|
||||
[port_peer]
|
||||
port = 2459
|
||||
ip = 0.0.0.0
|
||||
protocol = peer
|
||||
```
|
||||
|
||||
El puerto del protocolo de pares también sirve para [métodos especiales del puerto de pares](../../references/http-websocket-apis/peer-port-methods/index.md).
|
||||
|
||||
## Par de claves de nodo
|
||||
|
||||
Cuando un servidor se inicia por primera vez, genera un _par de claves de nodo_ para usarlo para identificarse en las comunicaciones del protocolo de pares. El servidor utiliza su clave para firmar todas sus comunicaciones del protocolo de pares. Esto hace posible identificar y verificar de manera confiable la integridad de los mensajes de otro servidor en la red peer-to-peer incluso si los mensajes de ese servidor están siendo transmitidos por pares no confiables.
|
||||
|
||||
El par de claves de nodo se guarda en la base de datos y se reutiliza cuando el servidor se reinicia. Si eliminas las bases de datos del servidor, crea un nuevo par de claves de nodo, lo que efectivamente le hace iniciar con una identidad diferente. Para reutilizar el mismo par de claves incluso si las bases de datos se eliminan, puedes configurar el servidor en el apartado `[node_seed]`. Para generar un valor adecuado para usar en el apartado `[node_seed]`, utiliza el [método validation_create][].
|
||||
|
||||
El par de claves de nodo también identifican otros servidores para propositos de [clustering](clustering.md) o [reservar huecos de pares](#pares-fijos-y-reservas-de-pares). Si tienes un cluster de servidores, debes configurar cada servidor en el cluster con un valor único en el apartado `[node_seed]`. Para más información de cómo configurar un cluster, ver [Servidores `rippled` clusterizados](../../infrastructure/configuration/peering/cluster-rippled-servers.md).
|
||||
|
||||
|
||||
## Pares fijos y reservas de pares
|
||||
|
||||
Normalmente, un servidor `rippled` intenta mantener un número saludable de pares, y se conecta automáticamente a pares no confiables hasta un número máximo. Puedes configurar un servidor `rippled` para permanecer conectado a servidores de pares específicos de varias maneras:
|
||||
|
||||
- Utiliza **Pares fijos** para permanecer siempre conectado a pares específicos basado en sus direcciones IP. Esto solo funciona si los pares tienen direcciones IP fijas. Usa el apartado `[ips_fixed]` para configurar pares fijos. Esto es una parte necesaria para [clustering](clustering.md) o [pares privados](#pares-privados). Los pares fijos están definidos en el fichero de configuración, pero los cambios solo se aplican una vez se reinicia el servidor. Los pares fijos son más útiles para mantener servidores conectados si esos servidores son administrados por la misma persona u organización.
|
||||
- Utiliza **Reservas de pares** para priorizar pares específicos. Si tu servidor tiene una reserva de pares para un par específico, entonces tu servidor siempre acepta peticiones de conexión desde ese par incluso si tu servidor está ya en su número máximo de pares conectados. (Esto puede causar que tu servidor _supere_ el número máximo de pares.) Identificas a un par reservado por su [par de claves de nodo](#par-de-claves-de-nodo), así puedes hacerlo incluso para pares con una direcciones IP dinamicas. Las reservas de pares son configurados a través de comandos de administrador y guardados en las bases de datos del servidor, por lo que se pueden ajustar mientras el servidor está online y son salvados durante los reinicios. Las reservas de pares más útiles para conectarse a servidor administrados por diferentes personas u organización. <!-- STYLE_OVERRIDE: prioritize -->
|
||||
|
||||
En los siguientes casos, un servidor `rippled` no se conecta a pares no confiables:
|
||||
|
||||
- Si el servidor es configurado como un [par privado](#pares-privados), se conecta _solo_ a sus pares fijos.
|
||||
- Si el servidor esta ejecutando en [modo solitario][] no se conecta a _ningún_ par.
|
||||
|
||||
|
||||
## Pares privados
|
||||
|
||||
Puedes configurar un servidor `rippled` para actuar como un servidor "privado" para mantener oculta su dirección IP del público general. Esta puede ser una precaución útil contra ataques de denegación de servicio e intentos de intrusión en servidores `rippled` importantes como los validadores de confianza. Para participar en la red peer-to-peer, un servidor privado debe estar configurado para conectarse a al menos un servidor no privado, que transmita sus mensajes al resto de la red.
|
||||
|
||||
**Atención:** Si configuras un servidor privado sin ningún [par fijo](#pares-fijos-y-reservas-de-pares), el servidor no puede conectarse a la red, por lo que no puede conocer el estado de la red, transmitir transacciones o participar en el proceso de consenso.
|
||||
|
||||
Configurar un servidor como un servidor privado tiene varios efectos:
|
||||
|
||||
- El servidor no hace conexiones salientes a otros servidores en la red peer-to-peer a menos que se haya configurado explícitamente para conectarse a esos servidores.
|
||||
- El servidor no acepta conexiones entrantes de otros servidores a menos que se haya configurado explícitamente para aceptar conexiones de esos servidores.
|
||||
- El servidor pide a sus pares directos no revelar su dirección IP a comunicaciones no confiables, incluyendo a la [respuesta de la API del peer crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md). Esto no afecta a las comunicaciones confiables como el [método peers admin][peers method].
|
||||
|
||||
Los servidores siempre piden a sus pares ocultar las direcciones IP de validadores, independientemente de la configuración del servidor privada. Esto ayuda a proteger validadores de ser sobrecargados por ataques de denegación de servicio.
|
||||
|
||||
**Atención:** Es posible modificar el código fuente de un servidor para que ignore esta petición y comparta las direcciones IP de sus pares inmediatos de todos modos. Debes configurar tu servidor privado para que se conecte solo a servidores que sepas que no están modificados de esta manera.
|
||||
|
||||
### Pros y contras de las configuraciones de pares
|
||||
|
||||
Para ser parte del XRP Ledger, un servidor `rippled` debe estar conectado al resto de la red abierta peer-to-peer. A grandes rasgos, hay tres categorías de configuraciones para cómo un servidor `rippled` se conecta a la red:
|
||||
|
||||
- Usando **pares descubiertos**. El servidor se conecta a cualquier servidor no confiable que encuentre y permanece conectado siempre que esos servidores se comporten adecuadamente. (Por ejemplo, no solicitan demasiados datos, sus conexiones de red son estables y parecen estar siguiendo la misma [red](parallel-networks.md).) Esto es lo predeterminado.
|
||||
- Como un **servidor privado utilizando proxies** ejecutado por la misma persona u organización. Los proxies son servidores stock `rippled` (también conectados a pares descubiertos) que mantienen una conexión de emparejamiento fija con el servidor privado.
|
||||
- Como un **servidor privado utilizando hubs públicos**. Esto es similar a utilizar proxies, pero depende de terceros específicos.
|
||||
|
||||
Los pros y contras de cada configuración son los siguientes:
|
||||
|
||||
|
||||
<table>
|
||||
<thead><tr>
|
||||
<th>Configuración</th> <th>Pros</th> <th>Contras</th>
|
||||
</tr></thead>
|
||||
<tbody>
|
||||
<tr><th>Pares descubiertos</th>
|
||||
<td><ul>
|
||||
<li><p>La configuración más simple, con una carga de mantenimiento baja.</p></li>
|
||||
<li><p>Crea la oportunidad para una gran cantidad de conexiones directas de pares. Tener más pares directos tiene varios beneficios. Tu servidor puede <a href="ledger-history.html#recuperar-el-histórico">recuperar histórico</a> de múltiples pares en paralelo, tanto al sincronizar como al rellenar el histórico. Como no todos los pares mantienen el histórico completo, tener acceso a una gama más amplia de datos históricos.</p></li>
|
||||
<li><p>Reduce la posibilidad de desconexión de la red porque tu servidor puede reemplazar los pares desconectados con otros nuevos.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>No te permite seleccionar los pares de tu servidor, lo que significa que no tienes idea de si tus pares pueden decidir actuar maliciosamente. Aunque los servidores `rippled` están diseñados para protegerse contra pares maliciosos, siempre existe el riesgo de que los pares maliciosos puedan atacar fallos en el software para afectar a tu servidor.</p></li>
|
||||
<li><p>Los pares de tu servidor pueden desconectarse o cambiar a menudo.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>Servidor privado utilizando proxies</th>
|
||||
<td><ul>
|
||||
<li><p>Configuración más segura y confiable cuando se implementa correctamente.</p></li>
|
||||
<li><p>Tan confiable y redundante como quieras hacerla.</p></li>
|
||||
<li><p>Puedes optimizar el rendimiento del servidor privado con <a href="clustering.html">clustering</a>.</p></li>
|
||||
<li><p>Te permite crear tantas conexiones directas de pares como desees. Tu servidor privado puede <a href="ledger-history.html#recuperar-el-histórico">obtener histórico</a> desde múltipes pares en paralelo. Dado que administras los pares, también puedes controlar cuanto histórico del ledger cada par puede mantener.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>Carga de mantenimiento y costos más altos debido a la ejecución de múltiples servidores.</p></li>
|
||||
<li><p>No elimina por completo la posibilidad de interrupciones en la conexión de pares. No importa cuántos proxies ejecutes, si todos existen en el mismo rack de servidores, entonces una interrupción de red o de luz puede afectar a todos ellos.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>Servidor privado utilizando hubs públicos</th>
|
||||
<td><ul>
|
||||
<li><p>Carga de mantenimiento baja con una pequeña cantidad de configuración.</p></li>
|
||||
<li><p>Proporciona acceso a conexiones seguras a la red.</p></li>
|
||||
<li><p>En comparación con la conexión utilizando proxies, es menos probable que cause que tu servidor privado se desconecte de la red debido a una interrupción simultánea de pares.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>Depende de terceros con una alta reputación para mantenerse confiable.</p></li>
|
||||
<li>
|
||||
<p>Puede hacer que tu servidor se desconecte de la red si los hubs públicos en los que confías están demasiado ocupados. Debido a la naturaleza de los hubs públicos, son los más populares y es posible que no puedan mantener una conexión estable abierta para todos.</p>
|
||||
<p>Para evitar este problema, usa más hubs públicos; cuanto más, mejor. También puede ayudar usar hubs no predeterminados, que son menos propensos a estar ocupados.</p>
|
||||
</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Configurando un servidor privado
|
||||
|
||||
Para configurar tu servidor como un servidor privado, establece la opción `[peer_private]` a `1` en el fichero de configuración. Para intrudciones más detalladas, ver [Configurar un servidor privado](../../infrastructure/configuration/peering/configure-a-private-server.md).
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Consenso](../consensus-protocol/index.md)
|
||||
- [Redes paralelas](parallel-networks.md)
|
||||
- **Tutoriales:**
|
||||
- [Cluster de servidores rippled](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
|
||||
- [Configurar un servidor privado](../../infrastructure/configuration/peering/configure-a-private-server.md)
|
||||
- [Configurar el Peer Crawler](../../infrastructure/configuration/peering/configure-the-peer-crawler.md)
|
||||
- [Redireccionar puertos para pares](../../infrastructure/configuration/peering/forward-ports-for-peering.md)
|
||||
- [Conectarse manualmente a un par específico](../../infrastructure/configuration/peering/manually-connect-to-a-specific-peer.md)
|
||||
- [Establecer número máximo de pares](../../infrastructure/configuration/peering/set-max-number-of-peers.md)
|
||||
- [Utilizar la reserva de pares](../../infrastructure/configuration/peering/use-a-peer-reservation.md)
|
||||
- **Referencias:**
|
||||
- [método peers][]
|
||||
- [método peer_reservations_add][]
|
||||
- [método peer_reservations_del][]
|
||||
- [método peer_reservations_list][]
|
||||
- [método connect][]
|
||||
- [método fetch_info][]
|
||||
- [Peer Crawler](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
html: rippled-server-modes.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Aprende sobre los modos de servidor rippled, incluyendo servidores stock, servidores validadores y servidores que se ejecutan en modo solitario.
|
||||
labels:
|
||||
- Servidor principal
|
||||
---
|
||||
# Modos de servidor rippled
|
||||
|
||||
El software del servidor `rippled` puede ejecutarse en varios modos dependiendo de su configuración, incluyendo:
|
||||
|
||||
- [**Modo P2P**](#modo-p2p) - Este es el modo principal del servidor: sigue la red peer-to-peer, procesa transacciones, y mantiene cierta cantidad de [histórico del ledger](ledger-history.md). Este modo se puede configurar para alguno o todos los siguientes roles:
|
||||
- [**Validador**](#validadores) - Ayuda a asegurar la red participando en el consenso.
|
||||
- [**Servidor API**](#servidores-api) - Proporciona [acceso API](../../tutorials/http-websocket-apis/build-apps/get-started.md) para leer datos del ledger compartido, enviar transacciones, y mirar la actividad en el ledger. Opcionalmente, puede ser un [**servidor full history**](#servidores-full-history), el cual guarda un registro completo de transacciones y el histórico del ledger.
|
||||
- [**Servidor hub**](#hubs-públicos) - Transmite mensajes entre muchos otros miembros de la red peer-to-peer.
|
||||
- [**Modo Reporting**](#modo-reporting) - Un modo especializado para servir consultas API desde una base de datos relacional. No participa en la red peer-to-peer, por lo que necesitas ejecutar un servidor en modo P2P y conectarle el servidor modo reporting usando una conexión gRPC de confianza.
|
||||
- [**Modo solitario**](#modo-solitario) - Un modo offline para pruebas. No se conecta a la red peer-to-peer ni usa consenso.
|
||||
|
||||
Tambien puedes ejecutar el ejecutable `rippled` como una aplicación cliente para acceder [APIs `rippled`](../../references/http-websocket-apis/index.md) localmente. (Dos instancias del mismo binario pueden ejecutarse uno al lado del otro en este caso; uno como un servidor, y el otro ejecutándose brevemente como cliente y luego apagarlo.)
|
||||
|
||||
Para más información sobre los comandos que ejecutar `rippled` en cada uno de estos modos, ver la [Referencia de línea de comandos](../../infrastructure/commandline-usage.md).
|
||||
|
||||
|
||||
## Modo P2P
|
||||
|
||||
El Modo P2P es el modo principal y predeterminado del servidor `rippled`, y puede manejar casi cualquier cosa que desees que haga tu servidor. Estos servidores forman una red peer-to-peer que procesa transacciones y mantiene el estado compartido del XRP Ledger. Si deseas enviar transacciones, leer datos del ledger o participar de otra manera en la red, tus solicitudes deben pasar por un servidor en Modo P2P en algún momento.
|
||||
|
||||
Los servidores en Modo P2P también pueden configurarse para proporcionar funcionalidades adicionales. Un servidor ejecutando en Modo P2P con un archivo de configuración mínimamente modificado también se llama un servidor de stock o _stock server_. Otras configuraciones incluyen:
|
||||
|
||||
- [Validador](#validadores)
|
||||
- [Servidor API](#servidores-api)
|
||||
- [Hubs públicos](#hubs-publicos)
|
||||
|
||||
Los servidores Modo P2P se conecta a [Mainnet](parallel-networks.md) por defecto.
|
||||
|
||||
|
||||
### Servidores API
|
||||
|
||||
Todos los servidores en Modo P2P proporcionan [APIs](../../references/http-websocket-apis/index.md) para propósitos como enviar transacciones, verificar balances y configuraciones, y administrar el servidor. Si consultas el XRP Ledger para obtener datos o enviar transacciones para uso comercial, puede ser útil [ejecutar tu propio servidor](index.md#razones-por-las-que-ejecutar-tu-propio-servidor).
|
||||
|
||||
#### Servidores Full History
|
||||
|
||||
A diferencia de algunas otras blockchains, el XRP Ledger no requiere que los servidores tengan un historial completo de transacciones para conocer el estado actual y procesar nuevas transacciones. Como operador de servidor, tú decides cuánto [histórico del ledger](ledger-history.md) almacenar en un momento dado. Sin embargo, un servidor en Modo P2P solo puede responder a solicitudes de API utilizando el historial del ledger que tiene disponible localmente. Por ejemplo, si conservas seis meses de historial, tu servidor no puede describir el resultado de una transacción de hace un año. Los servidores API con histórico completo o [full history](ledger-history.md#full-history) pueden informar de todas las transacciones y balances desde el inicio del XRP Ledger.
|
||||
|
||||
|
||||
### Hubs públicos
|
||||
|
||||
Un servidor hub es un servidor en Modo P2P con muchas [conexiones del protocolo de pares](peer-protocol.md) a otros servidores. Los servidores hub, especialmente los _hubs públicos_ que permiten conexiones desde Internet abierto, ayudan a la red del XRP Ledger a mantener una conectividad eficiente. Los hubs públicos exitosos encarnan las siguientes características:
|
||||
|
||||
- Buen ancho de banda.
|
||||
|
||||
- Conexiones con muchos pares confiables.
|
||||
|
||||
- Capacidad para transmitir mensajes de maneja confiable.
|
||||
|
||||
Para configurar tu servidor como un hub, aumenta el número máximo de pares permitidos y asegúrate de haber [redireccionado los puertos apropiados](../../infrastructure/configuration/peering/forward-ports-for-peering.md) a través de tu firewall y enrutador de NAT (traducción de dirección de red) según corresponda.
|
||||
|
||||
### Validadores
|
||||
|
||||
La robustez del XRP Ledger depende de una red interconectada de _validadores_ que confían mutuamente en algunos otros validadores para _no colisionar_. Además de procesar cada transacción y calcular el estado del ledger exactamente como otros servidores en Modo P2P, los validadores participan activamente en el [protocolo de consenso](../consensus-protocol/index.md). Si tú o tu organización dependen del XRP Ledger, es de tu interés contribuir al proceso de consenso ejecutando _un_ servidor como validador.
|
||||
|
||||
La validación utiliza solo una pequeña cantidad de recursos informáticos, pero no hay mucho beneficio para una sola entidad u organización en ejecutar varios validadores porque hacerlo no proporciona más protecciones contra las colisiones. Cada validador se identifica con un par de claves criptográficas único que debe ser gestionado cuidadosamente; múltiples validadores no deben compartir un par de claves. Por estas razones, la validación está desactivada de forma predeterminada.
|
||||
|
||||
Puedes habilitar de forma segura la validación en un servidor que también se utiliza para otros fines; este tipo de configuración se llama un _servidor multiuso_. Alternativamente, puedes ejecutar un _validador dedicado_ que no realice otras tareas, posiblemente en un [cluster](clustering.md) con otros servidores `rippled` en Modo P2P.
|
||||
|
||||
Para más información sobre como ejecutar un validador, ver [Ejecutar `rippled` como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).
|
||||
|
||||
|
||||
## Modo reporting
|
||||
|
||||
|
||||
El modo reporting es un modo especializado para servir solicitudes API de manera más eficiente. En este modo, el servidor obtiene los datos del ledger validados más recientes a través de [gRPC](../../infrastructure/configuration/configure-grpc.md) desde un servidor `rippled` separado en Modo P2P, luego carga esos datos en una base de datos relacional ([PostgreSQL](https://www.postgresql.org/)). El servidor en modo reporting no participa directamente en la red peer-to-peer, aunque puede reenviar solicitudes como el envío de transacciones al servidor en Modo P2P que utiliza.
|
||||
|
||||
Varios servidores en modo reporting pueden compartir acceso a una base de datos PostgreSQL y a un clúster [Apache Cassandra](https://cassandra.apache.org/) para servir una gran cantidad de historial sin que cada servidor necesite una copia redundante de todos los datos. Los servidores en modo reporting proporcionan estos datos a través de las mismas [`rippled` APIs](../../references/http-websocket-apis/index.md) con algunos cambios leves para adaptarse a las diferencias en cómo almacenan los datos subyacentes.
|
||||
|
||||
Especialmente, los servidores en modo reporting no informan sobre datos pendientes de validación del ledger o transacciones no validadas. Esta limitación es relevante para ciertos casos de uso que dependen de un acceso rápido a datos en flujo, como realizar arbitraje en el [exchange descentralizado](../tokens/decentralized-exchange/index.md).
|
||||
|
||||
<!-- TODO: link setup steps for Reporting Mode when those are ready -->
|
||||
|
||||
|
||||
## Modo solitario
|
||||
|
||||
En el modo solitario, el servidor opera sin conectarse a la red y sin participar en el proceso de consenso. Sin el proceso de consenso, debes avanzar manualmente el ledger y no se hace ninguna distinción entre "cerrado" y "validado" ledgers. Sin embargo, el servidor sigue proporcionando acceso a la API y procesa transacciones de la misma manera. Esto te permite:
|
||||
|
||||
- [Probar los efectos de enmiendas](../../infrastructure/testing-and-auditing/test-amendments.md) antes de que esas enmiendas hayan entrado en efecto en toda la red descentralizada.
|
||||
- [Crear un nuevo ledger génesis](../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md) desde el inicio.
|
||||
- [Cargar una versión de ledger existente](../../infrastructure/testing-and-auditing/load-a-saved-ledger-in-stand-alone-mode.md) desde el disco, luego reproducir transacciones específicas para recrear sus resultados y probar otras posibilidades.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Tutoriales:**
|
||||
- [Configurar `rippled`](../../infrastructure/configuration/index.md)
|
||||
- [Usar rippled en modo solitario](../../infrastructure/testing-and-auditing/index.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
html: the-clio-server.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: Clio es un servidor XRP Ledger optimizado para llamadas API.
|
||||
---
|
||||
# El servidor Clio
|
||||
|
||||
Clio es un servidor API del XRP Ledger optimizado para llamadas de WebSocket o HTTP API para datos del ledger validados.
|
||||
|
||||
Un servidor Clio no se conecta a la red peer-to-peer. En su lugar, extrae datos de un servidor `rippled` especifico que está conectado a la red P2P. Al manejar las llamadas API de manera eficiente, los servidores Clio pueden ayudar a reducir la carga en los servidores `rippled` que se ejecutan en modo P2P.
|
||||
|
||||
Clio almacena datos históricos del ledger y transacciones validadas en un formato eficiente de espacio, utilizando hasta 4 veces menos espacio que `rippled`. Clio utiliza Cassandra o ScyllaDB, lo que permite una capacidad de lectura escalable. Multiples servidores Clio pueden compartir acceso al mismo conjunto de datos, lo que le permite construir un clúster altamente disponible de servidores Clio sin necesidad de almacenamiento o cálculo de datos redundantes o computación
|
||||
|
||||
Clio requiere acceso a un servidor `rippled`, que pueda ejecutarse en la misma máquina que Clio o por separado.
|
||||
|
||||
Mientras que Clio ofrece las [APIs HTTP / WebSocket](../../references/http-websocket-apis/index.md) completas, por defecto, solo devuelve datos validados. Para cualquier solicitud que requiera acceso a la red P2P, Clio reenvía automáticamente la solicitud al servidor `rippled` en la red P2P y devuelve la respuesta.
|
||||
|
||||
## ¿Por qué debería ejecutar un servidor Clio?
|
||||
|
||||
Hay multitud de razones por las que podrías querer ejecutar tu propio servidor Clio, pero la mayoría se pueden resumir en: carga reducida en el/los servidor(es) `rippled` conectado(s) a la red P2P, menor uso de memoria y sobrecarga de almacenamiento, escalabilidad horizontal más fácil y mayor rendimiento para las solicitudes API.
|
||||
|
||||
* Carga reducida en el/los servidor(es) `rippled` - Un servidor Clio no se conecta a la red peer-to-peer. Utiliza gRPC para obtener datos validados de uno o más servidores `rippled` de confianza que están conectados a la red P2P. Por lo tanto, un servidor Clio maneja las solicitudes de manera más eficiente y reduce la carga en los servidores `rippled` que se ejecutan en modo P2P.
|
||||
|
||||
* Menor uso de memoria y sobrecarga de almacenamiento - Clio utiliza Cassandra como base de datos y almacena datos en un formato eficiente en espacio, utilizando hasta 4 veces menos espacio que `rippled`.
|
||||
|
||||
* Escalabilidad horizontal más fácil - Múltiples servidores Clio pueden compartir acceso al mismo conjunto de datos, lo que le permite construir un clúster altamente disponible de servidores Clio.
|
||||
|
||||
* Mayor rendimiento para las solicitudes API - Un servidor Clio extrae datos validados de uno o más servidores `rippled` confiables y almacena estos datos de manera eficiente. Por lo tanto, maneja las llamadas API de manera eficiente, lo que resulta en un mayor rendimiento y, en algunos casos, una latencia más baja también.
|
||||
|
||||
|
||||
## ¿Cómo funciona un servidor Clio?
|
||||
|
||||
[{% inline-svg file="/docs/img/clio-basic-architecture.svg" /%}](/docs/img/clio-basic-architecture.svg "Figura 1: ¿Cómo funciona un servidor Clio?")
|
||||
|
||||
Cuando un servidor Clio almacena datos del ledger validados, como metadatos de transacciones, estados de cuentas y encabezados de ledger, en un almacén de datos persistente.
|
||||
|
||||
Cuando un servidor Clio recibe una solicitud API, busca datos en estos almacenes de datos. Para solicitudes que requieren datos de la red P2P, el servidor Clio reenvía la solicitud a un servidor P2P y luego pasa la respuesta de vuelta al cliente.
|
||||
|
||||
Clio **siempre** reenvía a `rippled` si alguna de las siguientes condiciones es verdadera:
|
||||
|
||||
- `ledger_index` está establecido a `current` o `closed`.
|
||||
- `accounts`, `queue` o `full` están establecidos en `true` para la API de `ledger`.
|
||||
- `queue` está establecido en `true` para la API de `account_info`.
|
||||
- El método solicitado de API (`"command"`) es `submit`, `submit_multisigned`, `fee`, `ledger_closed`, `ledger_current`, `ripple_path_find`, `manifest`, `channel_authorize` o `channel_verify`.
|
||||
|
||||
## Ver también
|
||||
|
||||
- [Código fuente Clio](https://github.com/XRPLF/clio)
|
||||
- **Tutoriales:**
|
||||
- [Instalar servidor Clio en Ubuntu](../../infrastructure/installation/install-clio-on-ubuntu.md)
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
html: transaction-censorship-detection.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: El XRP Ledger proporciona un detector de censura de transacciones automatizado que está disponible en todos los servidores rippled.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Detección de censura de transacciones
|
||||
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}Nuevo en: rippled 1.2.0{% /badge %}
|
||||
|
||||
El XRP Ledger está diseñado para ser resistente a la censura. En apoyo a este diseño, el XRP Ledger proporciona un detector automatizado de censura de transacciones que está disponible en todos los servidores `rippled`, permitiendo que todos los participantes vean si la censura está afectando a la red.
|
||||
|
||||
Mientras un servidor `rippled` está sincronizado con la red, el detector rastrea todas las transacciones que deberían haber sido aceptadas en la última ronda de [consensus](../consensus-protocol/index.md) e incluidas en el último ledger validado. El detector emite mensajes de registro de severidad creciente cuando ve transacciones que no han sido incluidas en un ledger validado después de varias rondas de consenso.
|
||||
|
||||
|
||||
|
||||
## ¿Cómo funciona?
|
||||
|
||||
A alto nivel, así es cómo el detector de censura de transacciones funciona:
|
||||
|
||||
1. El detector agrega todas las transacciones en la propuesta de consenso inicial del servidor al rastreador.
|
||||
|
||||
2. Al cierre de la ronda de consenso, el detector elimina todas las transacciones incluidas en el ledger validado resultante del rastreador.
|
||||
|
||||
3. El detector emite un [mensaje de advertencia](#ejemplo-de-mensaje-de-advertencia) en el registro para cualquier transacción que permanezca en el rastreador durante 15 ledgers, mostrándola como una transacción potencialmente censurada. La presencia de la transacción en el rastreador en este momento significa que no ha sido incluida en un ledger validado después de 15 rondas de consenso. Si la transacción permanece en el rastreador durante otros 15 ledgers, el detector emite otro mensaje de advertencia en el registro.
|
||||
|
||||
Mientras la transacción permanezca en el rastreador, el detector continuará emitiendo un mensaje de advertencia en el registro cada 15 ledgers, hasta cinco mensajes de advertencia. Después del quinto mensaje de advertencia, el detector emite un [mensaje de error](#ejemplo-de-mensaje-de-error) final en el registro y luego deja de emitir mensajes de advertencia y error.
|
||||
|
||||
Si ves estos mensajes en el registro de tu servidor rippled, debes investigar por qué otros servidores no están incluyendo la transacción, comenzando con la suposición de que la causa es más probable que sea un [falso positivo](#potenciales-falsos-positivos) (error inocente) que una censura maliciosa.
|
||||
|
||||
## Ejemplo de mensaje de advertencia
|
||||
|
||||
Esto es un ejemplo de mensaje de advertencia emitido por el detector de censura de transacciones de que la transacción E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 permaneciese en el rastreador por 15 ledgers, desde el ledger 18851530 hasta el ledger 18851545.
|
||||
|
||||
```text
|
||||
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
|
||||
```
|
||||
|
||||
|
||||
## Ejemplo de mensaje de error
|
||||
|
||||
Este es un ejemplo de mensaje de error emitido por el detector de censura de transacciones después de que la transacción E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 permaneciese en el rastreador por 75 ledgers (5 conjuntos de 15 ledgers), desde el ledger 18851530 hasta el ledger 18851605.
|
||||
|
||||
```text
|
||||
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
|
||||
```
|
||||
|
||||
|
||||
## Potenciales falsos positivos
|
||||
|
||||
El detector de censura de transacciones puede emitir falsos positivos en ciertos escenarios. En este caso, un falso positivo significa que el detector ha marcado una transacción que ha permanecido en el rastreador durante 15 ledgers o más, pero por razones inocentes.
|
||||
|
||||
Aquí hay algunos escenarios que podrían causar que el detector emita mensajes de falsos positivos:
|
||||
|
||||
- Tu servidor está ejecutando una compilación con código diferente al resto de la red. Esto puede hacer que tu servidor aplique transacciones de manera diferente, lo que resulta en falsos positivos. Si bien este tipo de falsos positivos es poco probable en general, es crucial que ejecutes una versión compatible del servidor principal del XRP Ledger.
|
||||
|
||||
- Tu servidor está fuera de sincronización con la red y aún no lo ha notado.
|
||||
|
||||
- Los servidores en la red, incluido posiblemente tu propio servidor, tienen un error que les hace transmitir transacciones de manera inconsistente a otros servidores en la red.
|
||||
|
||||
Actualmente, no se conocen errores que causen este comportamiento inesperado. Sin embargo, si ves el impacto de lo que sospechas que es un error, considera reportarlo al programa [Ripple Bug Bounty](https://ripple.com/bug-bounty/).
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Principio de consenso y reglas](../consensus-protocol/consensus-principles-and-rules.md)
|
||||
- [Cola de transacciones](../transactions/transaction-queue.md)
|
||||
- **Tutoriales:**
|
||||
- [Envío confiable de transacciones](../transactions/reliable-transaction-submission.md)
|
||||
- [Entendiendo los mensajes de registro](../../infrastructure/troubleshooting/understanding-log-messages.md)
|
||||
- **Referencias:**
|
||||
- [Resultados de transacciones](../../references/protocol/transactions/transaction-results/index.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
19
@i18n/es-ES/docs/concepts/payment-types/bouncing-payments.md
Normal file
19
@i18n/es-ES/docs/concepts/payment-types/bouncing-payments.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
html: bouncing-payments.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: Cuando el propósito de un pago no esté claro, devuélvelo al remitente.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Devolver pagos
|
||||
|
||||
Cuando una de tus direcciones recibe un pago cuyo propósito no está claro, te recomendamos que intentes devolver el dinero a su remitente. Si bien esto requiere más trabajo que quedarse con el dinero, demuestra buena fe hacia los clientes. Puedes hacer que un operador rechace los pagos manualmente o crear un sistema para hacerlo automáticamente.
|
||||
|
||||
El primer requisito para devolver pagos es [monitorizar de manera robusta los pagos entrantes](robustly-monitoring-for-payments.md). ¡No querrás devolver accidentalmente a un cliente más de lo que te ha enviado! (Esto es particularmente importante si tu proceso de devolución está automatizado.) Usuarios maliciosos pueden tomar ventaja de una integración inocente al enviar [pagos parciales](partial-payments.md#exploit-de-pagos-parciales).
|
||||
|
||||
En segundo lugar, deberías enviar los pagos devueltos como Pagos Parciales (partial payments). Dado que terceras partes pueden manipular el coste de los caminos entre direcciones, los Pagos Parciales te permiten desprenderte de la cantidad completa sin preocuparte por los tipos de cambio dentro del XRP Ledger. Deberías publicar tu política de devolución de pagos como parte de tus términos de uso. Envía el pago devuelto desde una dirección operacional o una dirección de reserva.
|
||||
|
||||
Para enviar un Pago Parcial, activa el [flag `tfPartialPayment`](../../references/protocol/transactions/types/payment.md#flags-de-pago) en la transacción. Introduce la cantidad en el campo `Amount` con la cantidad que recibiste y omite el campo `SendMax`. Deberías utilizar el valor `SourceTag` del pago entrante como el `DestinationTag` de tu pago de devolución.
|
||||
|
||||
Para prevenir que dos sistemas estén devolviendo pagos uno al otro indefinidamente, puedes establecer un nuevo Source Tag para el pago de devolución saliente. Si recibes un pago inesperado cuyo Destination Tag coincide con el Source Tag de una devolución que enviaste, no lo rechaces nuevamente.
|
||||
67
@i18n/es-ES/docs/concepts/payment-types/checks.md
Normal file
67
@i18n/es-ES/docs/concepts/payment-types/checks.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
html: checks.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: Los cheques permiten a los usuarios a crear pagos diferidos que pueden ser cancelados o cobrados por los destinatarios deliberados.
|
||||
labels:
|
||||
- Cheques
|
||||
- Pagos
|
||||
- Tokens
|
||||
---
|
||||
# Cheques
|
||||
|
||||
|
||||
La función de Cheques permite a los usuarios crear pagos aplazados similares a cheques en papel. A diferencia de un depósito en garantía (escrow) o canal de pago (payment channel), los fondos no se reservan cuando se crea un cheque, por lo que el dinero solo se mueve cuando se cobra el cheque. Si el remitente no tiene los fondos en el momento en que se cobra un cheque, la transacción falla; los destinatarios pueden intentar nuevamente las transacciones fallidas hasta que el cheque expire.
|
||||
|
||||
Los Cheques del XRP Ledger pueden tener tiempos de vencimiento después de los cuales ya no pueden ser cobrados. Si el destinatario no cobra con éxito el Cheque antes de que expire, el Cheque ya no se podrá cobrar, pero el objeto permanece en el XRP Ledger hasta que alguien lo cancele. Cualquiera puede cancelar el Cheque después de que expire. Solo el remitente y el destinatario pueden cancelar el Cheque antes de que expire. El objeto del Cheque se elimina del ledger cuando el remitente cobra con éxito el cheque o alguien lo cancela.
|
||||
|
||||
## Casos de uso
|
||||
|
||||
- Los Cheques permiten a las personas intercambiar fondos utilizando un proceso familiar y aceptado por la industria bancaria.
|
||||
|
||||
- Si tu destinatario previsto utiliza autorización de deposito, [Deposit Authorization](../accounts/depositauth.md) para bloquear pagos directos de extraños, un cheque es una buena alternativa.
|
||||
|
||||
- Cobros de cheques flexibles. El destnatario puede canjear el Cheque entre un nínimo y un máximo.
|
||||
|
||||
|
||||
## Ciclo de vida de un cheque
|
||||
|
||||
1. El remitente envía una [transacción CheckCreate][], que define:
|
||||
- El destinatario.
|
||||
- Una fecha de caducidad.
|
||||
- La cantidad máxima que se puede cargar de su cuenta.
|
||||
|
||||
2. Cuando una transacción es procesada, el XRP Ledger crea un objeto `Check`. El cheque puede ser cancelado por el destinatario o el remitente con una [transacción CheckCancel][].
|
||||
|
||||
3. El destinatario envía una [transacción CheckCash][] que transfiere los fondos y destruye el objeto `Check`. Los destinatarios tienen dos opciones para cobrar los cheques:
|
||||
- Cantidad exacta: Se especifica la cantidad exacta de dinero a cobrar que no puede exceder el máximo del cheque.
|
||||
- Cantidad flexible: Se especifica una cantidad mínima para cobrar y el XRP Ledger manda tanto como sea posible hasta el máximo del cheque. Si el remitente no tiene fondos para cumplir al menos el mínimo específicado, la transacción falla.
|
||||
|
||||
4. Si el cheque vence antes de que el destinatario lo cobre, el objeto `Check` permanece hasta que alguien lo cancele.
|
||||
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
Para más información sobre Cheques en el XRP Ledger, ver:
|
||||
|
||||
- [Referencia transacción](../../references/protocol/transactions/types/index.md)
|
||||
- [CheckCreate][]
|
||||
- [CheckCash][]
|
||||
- [CheckCancel][]
|
||||
- [Tutoriales de cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/use-checks.md)
|
||||
- [Enviar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md)
|
||||
- [Buscar cheques por dirección del remitente](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md)
|
||||
- [Buscar cheques por dirección del destinatario](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md)
|
||||
- [Canjear un cheque por la cantidad exacta](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-an-exact-amount.md)
|
||||
- [Canjear un cheque por una cantidad flexible](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md)
|
||||
- [Cancelar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cancel-a-check.md)
|
||||
- [Enmienda Cheques][]
|
||||
|
||||
Para más información sobre funciones relacionadas, ver:
|
||||
|
||||
* [Autorización de deposito](../accounts/depositauth.md)
|
||||
* [Escrow](escrow.md)
|
||||
* [Tutorial de canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
html: cross-currency-payments.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: Los pagos entre divisas entregan atómicamente una moneda diferente a la que envían mediante la conversión a través de rutas y libros de pedidos.
|
||||
labels:
|
||||
- Entre divisas
|
||||
- Pagos
|
||||
---
|
||||
# Pagos entre divisas
|
||||
|
||||
El XRP Ledger te permite realizar pagos entre divisas de XRP y tokens. Los pagos entre divisas dentro del XRP Ledger son complétamente atómicos, lo que quiere decir que el pago se ejecuta por completo o no se ejecuta en absoluto.
|
||||
|
||||
Por defecto, los pagos entre divisas entregan una cantidad fija a su destino a un coste variable para su origen. Los pagos entre divisas también pueden ser [pagos parciales](partial-payments.md) que entregan una cantidad variable dentro de un límite de envío establecido.
|
||||
|
||||
|
||||
## Prerrequisitos
|
||||
|
||||
- Por definición, un pago entre divisas implica al menos dos monedas, lo que significa que al menos una fivisa involucrada debe ser un [token](../tokens/index.md) que no sea XRP.
|
||||
- Debe existir al menos una ruta o [Path](../tokens/fungible-tokens/paths.md) entre el remitente y el receptor, y la liquidez total a lo largo de todas las rutas debe ser suficiente para ejecutar el pago. Los pagos entre divisas se convierten de una divisa a otra consumiendo ofertas u [Offers](../tokens/decentralized-exchange/offers.md) en el [exchange descentralizado](../tokens/decentralized-exchange/index.md) del XRP Ledger.
|
||||
|
||||
|
||||
## Auto-puente
|
||||
|
||||
Los pagos entre divisas que intercambian un token por otro token pueden utilizar automáticamente XRP como puente entre los tokens, cuando esto reduce el coste del pago. Por ejemplo, un pago que envía de USD a MXN convierte automáticamente USD a XRP y luego XRP a MXN si hacerlo es más barato que convertir USD a MXN diréctamente. Operaciones más grandes pueden utilizar una combinación de conversiones directas (USD-MXN) y puentes automáticos (USD-XRP-MXN).
|
||||
|
||||
Para más información, ver auto-puente o [Auto-Bridging](../tokens/decentralized-exchange/autobridging.md).
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Tokens](../tokens/index.md)
|
||||
- [Exchange descentralizado](../tokens/decentralized-exchange/index.md)
|
||||
- [Paths](../tokens/fungible-tokens/paths.md)
|
||||
- **References:**
|
||||
- [Tipos de transacciones de pago][Payment transaction]
|
||||
- [método path_find][]
|
||||
- [método ripple_path_find][]
|
||||
- [Interpretando metadatos de pagos entre divisas](../transactions/finality-of-results/look-up-transaction-results.md#token-payments)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
html: direct-xrp-payments.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
title: Pagos directos en XRP
|
||||
description: Los pagos directos en XRP son la forma más rápida y sencilla de enviar valor en el XRP Ledger. Conoce ahora los conceptos básicos del ciclo de vida de pago directo en XRP.
|
||||
labels:
|
||||
- XRP
|
||||
- Pagos
|
||||
---
|
||||
# Pagos directos en XRP
|
||||
|
||||
La base de cualquier sistema financiero es la transferencia de valor. El método más rápido y sencillo en el XRP Ledger es un pago directo en XRP de una cuenta a otra. A diferencia de otros métodos de pago que requieren múltiples transacciones para completarse, un pago directo en XRP se ejecuta en una sola transacción sin intermediarios, y típicamente se completa en 8 segundos o menos. Solo puedes hacer pagos directos cuando XRP es la moneda enviada y recibida.
|
||||
|
||||
|
||||
|
||||
## Ciclo de vida de pagos XRP directos
|
||||
|
||||
1. El remitente crea una [transacción Payment][], que define los parámetros del pago. La transacción es un pago directo en XRP si XRP es la divisa enviada y recibida.
|
||||
|
||||
2. El procesamiento de la transacción verifica los parámetros y circunstancias de la transacción; si la comprobación falla, el pago falla.
|
||||
|
||||
- Todos los campos están formateados correctamente.
|
||||
- La dirección de envío es una cuenta activada en el XRP Ledger.
|
||||
- Todas las firmas proporcionadas son válidas para la dirección de envío.
|
||||
- La dirección de destino es diferente que la dirección de envío.
|
||||
- El remitente tiene suficiente XRP en balance para enviar el pago.
|
||||
|
||||
2. El procesamiento del pago comprueba la dirección de destino; si alguna comprobación falla, el pago falla.
|
||||
|
||||
- Si la dirección de recepción está activada, el motor hace comprobaciones adicionales basados en sus configuraciones, como la autorización de depósito o [Deposit Authorization](../accounts/depositauth.md).
|
||||
- Si la dirección de recepción no está activada, comprueba si el pago enviará suficiente XRP para cumplir con el mínimo del requisito de la [reserva de cuenta](../accounts/reserves.md). Si la reserva se cumple, una nueva cuenta es creada para la dirección y el balance inicial es la cantidad recibida.
|
||||
|
||||
4. El ledger quita y acredita a las correspondientes cuentas.
|
||||
|
||||
**Nota:** Al remitente también se le carga el [coste de transacción](../transactions/transaction-cost.md) en XRP.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Tutoriales:**
|
||||
- [Enviar XRP (Tutorial interactivo)](../../tutorials/how-tos/send-xrp.md)
|
||||
- [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
|
||||
- **Referencias:**
|
||||
- [Transacción Payment][]
|
||||
- [Resultados de Transaction](../../references/protocol/transactions/transaction-results/index.md)
|
||||
- [método account_info][] - para comprobar balances en XRP
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
96
@i18n/es-ES/docs/concepts/payment-types/escrow.md
Normal file
96
@i18n/es-ES/docs/concepts/payment-types/escrow.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
html: escrow.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: El Escrow retiene fondos hasta que las condiciones específicas se cumplan.
|
||||
labels:
|
||||
- Escrow
|
||||
---
|
||||
# Escrow
|
||||
|
||||
Tradicionalmente, un escrow es un contrato entre dos partes para facilitar transacciones financieras. Un tercero imparcial recibe y retiene los fondos, y solo los libera al destinatario previsto cuando se cumplen las condiciones especificadas en el contrato. Este método asegura que ambas partes cumplan con sus obligaciones.
|
||||
|
||||
El XRP Ledger lleva el escrow un paso más allá, reemplazando al tercero con un sistema automatizado integrado en el ledger. Un escrow bloquea el XRP, que no puede ser utilizado o destruido hasta que se cumplan las condiciones.
|
||||
|
||||
## Tipos de escrow
|
||||
|
||||
El XRP Ledger soporta tres tipos de escrow:
|
||||
|
||||
- **Escrow basado en el tiempo:** Los fondos solo están disponibles después de que haya pasado cierta cantidad de tiempo.
|
||||
- **Escrow condicional:** Este escrow se crea con una condición correspondiente y un cumplimiento. La condición sirve como un bloqueo en los fondos y no se liberará hasta que se proporcione la clave de cumplimiento correcta.
|
||||
- **Escrow combinado:** Este escrow combina las características de un escrow basado en el tiempo y uno condicional. El escrow es completamente inaccesible hasta que pase el tiempo especificado, después de lo cual los fondos pueden ser liberados proporcionando el cumplimiento correcto.
|
||||
|
||||
## Ciclo de vida de un escrow
|
||||
|
||||
1. El remitente crea un escrow utilizando la transacción `EscrowCreate`. Esta transacción define:
|
||||
|
||||
- Una cantidad de XRP para bloquear.
|
||||
- Las condiciones para liberar el XRP.
|
||||
- El destinatario del XRP.
|
||||
|
||||
2. Cuando se procesa la transacción, el XRP Ledger crea un objeto `Escrow` que retiene el XRP en el escrow.
|
||||
|
||||
3. El destinatario envía una transacción `EscrowFinish` para entregar el XRP. Si las condiciones se han cumplido, esto destruye el objeto `Escrow` y entrega el XRP al destinatario.
|
||||
|
||||
**Nota:** Si el escrow tiene una fecha de caducidad y no se completa con éxito antes de este tiempo, el escrow se caduca. Un escrow caducado permanece en el ledger hasta que una transacción `EscrowCancel` lo cancele, destruyendo el objeto `Escrow` y devuelve el XRP al remitente.
|
||||
|
||||
## Estados del escrow
|
||||
|
||||
El siguiente diagrama muestra los estados por los que puede pasar un escrow:
|
||||
|
||||
[](/docs/img/escrow-states.png)
|
||||
|
||||
El diagrama muestra tres casos diferentes para tres posibles combinaciones de los escrows de tiempo "terminar trás" (campo `FinishAfter`), cripto-condición (campo `Condition`), y tiempo de caducidad (campo `CancelAfter`):
|
||||
|
||||
- **Escrow basado en el tiempo (izquierda):** Con solo un tiempo de finalización, el escrow se crea en el estado **Retenido**. Después de que haya pasado un tiempo especificado, se convierte en **Preparado** y cualquiera puede finalizarlo. Si el escrow tiene una fecha de caducidad y nadie finaliza el escrow antes de que el tiempo pase, entonces el escrow pasa a estar **Caducado**. En el estado de caducado, un escrow no puede finalizarse, y cualquiera puede cancelarlo. Si el escrow no tiene un campo `CancelAfter`, nunca caduca y nunca puede cancelarse.
|
||||
|
||||
- **Escrow combinado (centro):** Si el escrow especifica tanto como una criptocondición (campo `Condition`) _y_ una fecha "terminar tras" (campo `FinishAfter`), el escrow es **Retenido** hasta que la fecha "terminar-tras" ha pasado. Luego se convierte en **Condicionalmente preparado**, y puede finalizarlo si se suministra el cumplimiento correcto de la criptocondición. Si el escrow tiene una fecha de caducidad (campo `CancelAfter`), y nadie lo completa antes de que pase ese tiempo, entonces el escrow se convierte en **Caducado**. En el estado de caducado, un escrow no se puede finalizar, y cualquiera puede cancelarlo. Si el escrow no tiene un campo `CancelAfter`, nunca caducará y no podrá ser cancelado.
|
||||
|
||||
- **Escrow condicional (derecha):** Si el escrow especifica una criptocondición (campo `Condition`) y no por una fecha "terminar trás", el escrow se convierte en **Condicionalmente preparado** inmediatamente cuando se crea. Durante este tiempo, cualquiera puede finalizar el escrow, pero solo si suministran el cumplimiento correcto a la criptocondición. Si nadie finaliza el escrow antes de la fecha de caducidad (campo `CancelAfter`), el escrow se convierte en **Caducado**. (Un escrow sin una fecha de "finalizar-tras" _debe_ tener una fecha de caducidad.) En el estado de caducado, el escrow no puede ser finalizado, y cualquiera puede cancelarlo.
|
||||
|
||||
|
||||
## Limitaciones
|
||||
|
||||
- El escrow solo funciona con XRP, no con tokens.
|
||||
- Los costes pueden hacerlo poco práctico para cantidades pequeñas.
|
||||
- El escrow requiere de dos transacciones: una para crear el escrow, y una para finalizarlo o cancelarlo. Las criptocondiciones incurren en un [coste de transacción](../transactions/transaction-cost.md) mayor al usual.
|
||||
- Mientras que el escrow no se completa, el remitente es responsable del [requisito de reserva](../accounts/reserves.md) del objeto del `Escrow`.
|
||||
- No puedes crear un escrow con valores de fechas pasados.
|
||||
- Las liberaciones y caducidad se resuelven en [tiempos de cierre de ledgers](../ledgers/ledger-close-times.md). En la práctica, los tiempos de liberaciones o caducidad pueden variar en 5 segundos respecto a los cierres de ledgers.
|
||||
- El único tipo de criptocondición aceptado es PREIMAGE-SHA-256.
|
||||
|
||||
|
||||
## Coste de la transacción EscrowFinish
|
||||
|
||||
Cuando uses criptocondiciones, la transacción EscrowFinish debe pagar un [mayor coste de transacción](../transactions/transaction-cost.md#special-transaction-costs) por la carga de procesamiento involucrada en la verificación de la criptocondición introducida.
|
||||
|
||||
El coste de transacción adicional requerido es proporcional al tamaño de la condición introducida. Si la transacción es multi-firma o [multi-signed](../accounts/multi-signing.md), el coste de la multi-firma es añadido al coste de la introducción de la condición.
|
||||
|
||||
Actualmente, un EscrowFinish con introducción requiere un mínimo de coste de transacción de **330 [drops de XRP](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts) más 10 drops por cada 16 bytes del tamaño de la introducción**.
|
||||
|
||||
**Nota:** La fórmula de arriba está basada en la asunción de que el coste de referencia de la transacción es 10 drops de XRP.
|
||||
|
||||
Si el [coste de votar](../consensus-protocol/fee-voting.md) cambia el valor de `reference_fee`, la fórmula escala basado en el nuevo coste de referencia. La fórmula general de una transacción EscrowFinish con un crypto-cumplimiento es como sigue:
|
||||
|
||||
```
|
||||
reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
Para más información sobre Escrow en el XRP Ledger, consulta lo siguiente:
|
||||
|
||||
- [Tutoriales Escrow](../../tutorials/how-tos/use-specialized-payment-types/use-escrows/index.md)
|
||||
- [Referencia de transacciones](../../references/protocol/transactions/index.md)
|
||||
- [Transacción EscrowCreate][]
|
||||
- [Transacción EscrowFinish][]
|
||||
- [Transacción EscrowCancel][]
|
||||
- [Referencia Ledger](../../references/protocol/ledger-data/index.md)
|
||||
- [Objeto Escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
|
||||
|
||||
|
||||
Para más información sobre el bloqueo de 55 mil millones de Ripple, consulta [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/).
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
16
@i18n/es-ES/docs/concepts/payment-types/index.md
Normal file
16
@i18n/es-ES/docs/concepts/payment-types/index.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
html: payment-types.html
|
||||
parent: concepts.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
title: Point-to-Point & Specialized Ledger Payment Types
|
||||
description: Mientras que el XRP Ledger admite pagos XRP de punto a punto, también es compatible con tipos de pago más especializados. Descubre qué métodos de pago del ledger aquí.
|
||||
---
|
||||
# Ledger Payment Types
|
||||
|
||||
|
||||
El XRP Ledger admite pagos de XRP de punto a punto junto con otros tipos de pago más especializados.
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
140
@i18n/es-ES/docs/concepts/payment-types/partial-payments.md
Normal file
140
@i18n/es-ES/docs/concepts/payment-types/partial-payments.md
Normal file
@@ -0,0 +1,140 @@
|
||||
---
|
||||
html: partial-payments.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: Los pagos parciales restan costes a la cantidad enviada, entregando una cantidad flexible. Los pagos parciales son útiles para devolver pagos no deseados sin incurrir en costes adicionales.
|
||||
labels:
|
||||
- Pagos
|
||||
- Seguridad
|
||||
---
|
||||
# Pagos parciales
|
||||
|
||||
El remitente de cualquier [transacción de pago][] puede habilitar el [flag de"Partial Payment"](../../references/protocol/transactions/types/payment.md#payment-flags) y enviar un pago que entregue menos de lo que indica el campo `Amount`. Al procesar cualquier Pago, utiliza el campo de metadatos `delivered_amount`, no el campo `Amount`. El `delivered_amount` es la cantidad que un pago realmente entregó.
|
||||
|
||||
Si un Pago no habilita el flag de Pago Parcial, el campo `Amount` de una [transacción Payment][] en el XRP Ledger especifica la cantidad a entregar después de cobrar por tasas de cambio y [costes de transferencia](../tokens/transfer-fees.md). El flag de Pago Parcial ([`tfPartialPayment`](../../references/protocol/transactions/types/payment.md#payment-flags)) permite que un pago tenga éxito al reducir la cantidad recibida en lugar de aumentar la cantidad enviada. Los pagos parciales son útiles para [devolver pagos](bouncing-payments.md) sin incurrir en costos adicionales para uno mismo.
|
||||
|
||||
La cantidad de XRP utilizada para el [coste de transacción](../transactions/transaction-cost.md) siempre se deduce de la cuenta del remitente, independientemente del tipo de transacción. Este coste de transacción, o comisión, no se incluye en la `Amount`.
|
||||
|
||||
Los pagos parciales se pueden utilizar para explotar integraciones ingenuas con el XRP Ledger para robar dinero de exchanges y gateways. La sección [Explotación de Pagos Parciales](#exploit-de-pagos-parciales) de este documento describe cómo funciona esta explotación y cómo puedes evitarla.
|
||||
|
||||
## Semántica
|
||||
|
||||
### Sin pagos parciales
|
||||
|
||||
Al enviar un Pago que no utiliza el flag de Pago Parcial, el campo `Amount` de la transacción especifica la cantidad exacta a entregar, y el campo `SendMax` especifica la cantidad máxima y la divisa a enviar. Si un pago no puede entregar la cantidad completa de `Amount` sin exceder el parámetro `SendMax`, o si la cantidad completa no se puede entregar por cualquier otro motivo, la transacción falla. Si el campo `SendMax` se omite de las instrucciones de la transacción, se considera igual a la `Amount`. En este caso, el pago solo puede tener éxito si la cantidad total de las tarifas es 0.
|
||||
|
||||
En otras palabras:
|
||||
|
||||
```
|
||||
Cantidad + (costes) = (cantidad enviada) ≤ SendMax
|
||||
```
|
||||
|
||||
En esta fórmula, "costes" o fees se refiere a [costes de transferencia](../tokens/transfer-fees.md) y tipos de cambio de las divisas. La "cantidad enviada" y la cantidad enviada (`Amount`) pueden estar denominadas en distintas divisas y convertirse por la consumición de Ofertas en el exchange descentralizado del XRP Ledger.
|
||||
|
||||
**Nota:** El campo `Fee` de la transacción se refiere al [coste de transacción](../transactions/transaction-cost.md) en XRP, que se destruye para enviar la transacción a la red. El coste de transacción exacto especificado se carga siempr al remitente y se separa completamente de los cálculos de costes para cualquier tipo de pago.
|
||||
|
||||
### Con pagos parciales
|
||||
|
||||
Cuando se envía un Pago que tiene habilitado el flag de Pago Parcial, el campo `Amount` de la transacción especifica una cantidad máxima a entregar. Los pagos parciales pueden tener éxito al enviar _parte_ del valor previsto a pesar de limitaciones que incluyen costes, falta de liquidez, falta de espacio en las líneas de confianza (trustlines) de la cuenta receptora, u otras razones.
|
||||
|
||||
El campo opcional `DeliverMin` especifica una cantidad mínima a entregar. El campo `SendMax` funciona de la misma manera que con los pagos no parciales. La transacción de pago parcial tiene éxito si entrega cualquier cantidad igual o mayor que el campo `DeliverMin` sin exceder la cantidad `SendMax`. Si el campo `DeliverMin` no está especificado, un pago parcial puede tener éxito al entregar cualquier cantidad positiva.
|
||||
|
||||
En otras palabras:
|
||||
|
||||
```
|
||||
Cantidad ≥ (Cantidad enviada) = SendMax - (Costes) ≥ DeliverMin > 0
|
||||
```
|
||||
|
||||
### Limitaciones de los pagos parciales
|
||||
|
||||
Los pagos parciales tienen las siguientes limitaciones:
|
||||
|
||||
- Un pago parcial no puede proporcionar el XRP para crear una dirección; en este caso se devuelve el [código de resultado][] `telNO_DST_PARTIAL`.
|
||||
- Pagos directoss de XRP a XRP no pueden ser pagos parciales; este caso devuelve el [código de resultado][] `temBAD_SEND_XRP_PARTIAL`.
|
||||
- Sin embargo, los pagos entre divisas que involucran a XRP como una de las divisas _pueden_ ser pagos parciales.
|
||||
|
||||
[código de resultado]: ../../references/protocol/transactions/transaction-results/index.md
|
||||
|
||||
### El campo `delivered_amount`
|
||||
|
||||
Para ayudar a entender cuánto entregó realmente un pago parcial, los metadatos de una transacción de Pago exitosa incluyen un campo `delivered_amount`. Este campo describe la cantidad realmente entregada, en el [mismo formato](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts) que el campo `Amount`.
|
||||
|
||||
Para pagos no parciales, el campo `delivered_amount` de los metadatos de la transacción es igual al campo `Amount` de la transacción. Cuando un pago entrega [tokens](../tokens/index.md), el campo `delivered_amount` puede ser ligeramente diferente al campo `Amount` debido al redondeo.
|
||||
|
||||
La cantidad entregada **no está disponible** para transacciones que cumplen **ambos** de los siguientes criterios:
|
||||
|
||||
- Es un pago parcial
|
||||
- Está incluido en un ledger validado anterior al 20 de enero de 2014
|
||||
|
||||
Si ambas condiciones son verdaderas, entonces `delivered_amount` contiene el valor del string `unavailable` en lugar de una cantidad real. Si esto ocurre, solo puedes determinar la cantidad entregada real leyendo los `AffectedNodes` en los metadatos de la transacción. Si la transacción entregó tokens y el `issuer` del `Amount` es la misma cuenta que la dirección `Destination`, la cantidad entregada puede dividirse entre varios miembros de `AffectedNodes` que representan líneas de confianza (trustlines) con distintas contrapartes.
|
||||
|
||||
Puedes encontrar el campo `delivered_amount` en los siguientes lugares:
|
||||
|
||||
| API | Método | Campo |
|
||||
|-----|--------|-------|
|
||||
| [JSON-RPC / WebSocket][] | [método account_tx][] | `result.transactions` miembros del array `meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [método tx][] | `result.meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [método transaction_entry][] | `result.metadata.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [método ledger][] (con las transacciones ampliadas) | `result.ledger.transactions` miembros del array `metaData.delivered_amount` |
|
||||
| [WebSocket][] | [subscripciones Transaction](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Mensajes de subscripción de `meta.delivered_amount` |
|
||||
| ripple-lib v1.x | método `getTransaction` | `outcome.deliveredAmount` |
|
||||
| ripple-lib v1.x | método `getTransactions` | miembros del array `outcome.deliveredAmount` |
|
||||
|
||||
[WebSocket]: ../../references/http-websocket-apis/index.md
|
||||
[JSON-RPC / WebSocket]: ../../references/http-websocket-apis/index.md
|
||||
|
||||
## Exploit de pagos parciales
|
||||
|
||||
Si la integración de una institución financiera con el XRP Ledger asume que el campo `Amount` de un Pago es siempre la cantidad completa entregada, actores maliciosos podrían aprovechar esa suposición para robar dinero de la institución. Este exploit puede utilizarse contra pasarelas, exchanges o comerciantes siempre que el software de esas instituciones no procese los pagos parciales correctamente.
|
||||
|
||||
**La forma correcta de procesar las transacciones de Pago entrantes es utilizar [el campo `delivered_amount` de los metadatos](#the-delivered_amount-field),** no el campo `Amount`. De este modo, una institución nunca se equivocará sobre cuanto recibe _realmente_.
|
||||
|
||||
|
||||
### Pasos del escenario del Exploit
|
||||
|
||||
Para realizar un exploit a una institución financiera vulnerable, un actor malicioso puede hacer lo siguiente:
|
||||
|
||||
1. El actor malicioso envía una transacción de Pago a la institución. Esta transacción tiene un campo `Amount` grande y tiene el flag de **`tfPartialPayment`** activado.
|
||||
2. El pago parcial tiene éxito (código de resultado `tesSUCCESS`) pero en realidad entrega una cantidad muy pequeña de la divisa especificada.
|
||||
3. La institución vulnerable lee el campo `Amount` sin mirar el campo `Flags` o el campo de metadatos `delivered_amount`.
|
||||
4. La institutución vulnerable acredita al actor malicioso en un sistema externo, como el propio ledger de la institución, por el `Amount` completo, a pesar de recibir solo un `delivered_amount` pequeño en el XRP Ledger.
|
||||
5. El actor malicioso retira tanto saldo como sea posible antes de que la institución vulnerable note la discrepancia.
|
||||
- Los actores maliciosos suelen preferir convertir el saldo a otra criptomoneda como Bitcoin, porque las transacciones de blockchain suelen ser irreversibles. Con un retiro a un sistema de moneda fiduciaria, la institución financiera podría revertir o cancelar la transacción varios días después de que se ejecute inicialmente.
|
||||
- En el caso de un exchange, el actor malicioso también puede retirar un saldo de XRP directamente de nuevo al XRP Ledger.
|
||||
|
||||
En el caso de un comerciante, el orden de las operaciones es ligeramente diferente, pero el concepto es el mismo:
|
||||
|
||||
1. El actor malicioso solicita comprar una gran cantidad de bienes o servicios.
|
||||
2. El comerciante vulnerable factura al actor malicioso por el precio de esos bienes o servicios.
|
||||
3. El actor malicioso envía una transacción de Pago al comerciante. Esta transacción tiene un campo `Amount` grande y tiene el flag **`tfPartialPayment`** activado.
|
||||
4. El pago parcial tiene éxito (código de resultado `tesSUCCESS`) pero entrega solo una cantidad muy pequeña de la divisa especificada.
|
||||
5. El comerciante vulnerable lee el campo `Amount` de la transacción sin mirar el campo `Flags` o el campo de los metadatos `delivered_amount`.
|
||||
6. El comerciante vulnerable trata la factura como pagada y proporciona los bienes o servicios al actor malicioso, a pesar de recibir solo una mucho menor `delivered_amount` en el XRP Ledger.
|
||||
7. El actor malicioso utiliza, revende, o se marcha con los bienes y servicios antes de que el comerciantes note la discrepancia.
|
||||
|
||||
### Mitigaciones adicionales
|
||||
|
||||
Utilizar [el campo `delivered_amount`](#the-delivered_amount-field) al procesar transacciones entrantes es suficiente para evitar este exploit. Aún así, prácticas de negocio proactivas adicionales también pueden evitar o mitigar la probabilidad de esta o exploits similares. Por ejemplo:
|
||||
|
||||
- Añade chequeos adicionales a la lógica de tu negocio para procesar los retiros. Nunca proceses un retiro si el balance total que tienes en el XRP Ledger no coincide con tus activos y obligaciones esperados.
|
||||
- Sigue las directrices "Know Your Customer" y verifica estrictamente las identidades de tus clientes. Puede que reconozcas y bloquees usuarios maliciosos de antemano, o emprender acciones legales contra el actor malicioso que genera exploits a tu sistema.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Herramientas:**
|
||||
- [Remitente de la transacción](/resources/dev-tools/tx-sender)
|
||||
- **Conceptos:**
|
||||
- [Transacciones](../transactions/index.md)
|
||||
- **Tutoriales:**
|
||||
- [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md)
|
||||
- [Monitorear pagos recibidos con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
|
||||
- [Usar tipos de pagos especializados](../../tutorials/how-tos/use-specialized-payment-types/index.md)
|
||||
- [Listar XRP en un Exchange](../../use-cases/defi/list-xrp-as-an-exchange.md)
|
||||
- **Referencias:**
|
||||
- [Transacción de Pago][]
|
||||
- [Metadatos de transacción](../../references/protocol/transactions/metadata.md)
|
||||
- [método account_tx][]
|
||||
- [método tx][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
52
@i18n/es-ES/docs/concepts/payment-types/payment-channels.md
Normal file
52
@i18n/es-ES/docs/concepts/payment-types/payment-channels.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
html: payment-channels.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: Los canales de pago que activan pagos XRP asíncronos rápidos que pueden dividirse en incrementos muy pequeños y liquidarse más después.
|
||||
labels:
|
||||
- Canales de pago
|
||||
- Smart Contracts
|
||||
---
|
||||
# Canales de pago
|
||||
|
||||
Los Canales de Pago son una función avanzada para enviar pagos de XRP "asíncronos" que pueden dividirse en incrementos muy pequeños y liquidarse más tarde.
|
||||
|
||||
El XRP para un canal de pago se reserva temporalmente. El remitente crea reclamaciones o _Claims_ contra el canal, que el destinatario verifica sin enviar una transacción al XRP Ledger o esperar a que se apruebe una nueva versión del ledger por [consenso](../consensus-protocol/index.md). (Este es un proceso _asíncrono_ porque ocurre separado del patrón habitual de obtener transacciones aprobadas por consenso). En cualquier momento, el destinatario puede _canjear_ una reclamación (Claim) para recibir una cantidad de XRP autorizada por esa _Claim_. Liquidar una _Claim_ de esta manera utiliza una transacción estándar del XRP Ledger, como parte del proceso de consenso habitual. Esta única transacción puede abarcar cualquier cantidad de transacciones garantizadas por _Claims_ más pequeñas.
|
||||
|
||||
Debido a que las reclamaciones pueden verificarse individualmente pero liquidarse en bloque más adelante, los canales de pago hacen posible realizar transacciones a una velocidad limitada solo por la capacidad de los participantes para crear y verificar las firmas digitales de esas Reclamaciones. Este límite se basa principalmente en la velocidad del hardware de los participantes y la complejidad de los algoritmos de firma. Para obtener la máxima velocidad, utiliza firmas Ed25519, que son más rápidas que las firmas ECDSA secp256k1 predeterminadas del XRP Ledger. La investigación ha [demostrado la capacidad de crear más de 100.000 firmas Ed25519 por segundo y verificar más de 70.000 por segundo](https://ed25519.cr.yp.to/ed25519-20110926.pdf) en hardware estándar en 2011.
|
||||
|
||||
|
||||
## ¿Por qué usar canales de pago?
|
||||
|
||||
El proceso de usar un canal de pago siempre implica dos partes, un pagador y un beneficiario. El pagador es una persona o institución que utiliza el XRP Ledger y es cliente del beneficiario. El beneficiario es una persona o empresa que recibe XRP como pago por bienes o servicios.
|
||||
|
||||
Los Canales de Pago no especifican intrínsecamente nada sobre lo que puedes comprar y vender con ellos. Sin embargo, los tipos de bienes y servicios que son adecuados para los canales de pago son:
|
||||
|
||||
- Cosas que pueden transmitirse casi instantaneamente, como artículos digitales
|
||||
- Cosas baratas, donde el coste de procesar una transacción es una parte no trivial del precio
|
||||
- Cosas que normalmente se compran en bloque, donde la cantidad exacta deseada no se conoce de antemano
|
||||
|
||||
|
||||
## Ciclo de vida de un canal de pago
|
||||
|
||||
El siguiente diagrama resume el ciclo de vida de un canal de pago:
|
||||
|
||||
[{% inline-svg file="/docs/img/paychan-flow.svg" /%}](/docs/img/paychan-flow.svg "Diagrama de flujo de un canal de pago")
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos relacionados:**
|
||||
- [Escrow](escrow.md), una función similar para pagos XRP condicionales de mayor valor y menor velocidad.
|
||||
- **Tutoriales y casos de uso:**
|
||||
- [Utilizar canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md), un tutorial que guía a través del proceso de utilizar un canal de pago.
|
||||
- [Abrir un canal de pago para activar una red de intercambio](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/open-a-payment-channel-to-enable-an-inter-exchange-network.md)
|
||||
- **Referencias:**
|
||||
- [Método channel_authorize][]
|
||||
- [Método channel_verify][]
|
||||
- [Objeto PayChannel](../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)
|
||||
- [Transacción PaymentChannelClaim][]
|
||||
- [Transacción PaymentChannelCreate][]
|
||||
- [Transacción PaymentChannelFund][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
html: robustly-monitoring-for-payments.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: Recomendaciones para monitorizar pagos entrantes de una variedad e posibles irregularidades.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Monitoreo robusto de pagos
|
||||
|
||||
Para verificar robustamente los pagos entrantes, los emisores deberían hacer lo siguiente:
|
||||
|
||||
* Mantener un registro de la transacción y el ledger más recientemente procesados. De esta manera, si pierdes temporalmente la conectividad, sabrás hasta dónde retroceder.
|
||||
* Verificar el código de resultado de cada pago entrante. Algunos pagos ingresan al ledger para cobrar una tarifa contra el spam, incluso si fallan. Solo las transacciones con el código de resultado `tesSUCCESS` pueden cambiar saldos que no sean de XRP. Solo las transacciones de un ledger validado son definitivas.
|
||||
* Mirar los [pagos parciales](partial-payments.md). Los pagos con el flag de pago parcial activado pueden ser condierados "exitosos" si se entrega cualquier cantidad distinta a cero, incluso cantidades minúsculas.
|
||||
* Comprobar la transacción en busca del [campo `delivered_amount`](partial-payments.md#el-campo-delivered_amount). Si está presente, el campo indica cuanto dinero _realmente_ se envió a la dirección `Destination`.
|
||||
* En xrpl.js, puedes usar el [método `xrpl.getBalanceChanges()`](https://js.xrpl.org/modules.html#getBalanceChanges) para ver cuánto recibió cada dirección. En algunos casos, esto puede dividirse en varias partes en diferentes líneas de confianza (trustlines).
|
||||
* Algunas transacciones cambian tus balances sin ser pagos directos hacia o desde una de tus direcciones.
|
||||
|
||||
Para simplificar las cosas para tus clientes, te recomendamos aceptar pagos tanto en tu dirección operacional como en tus direcciones de emisoras.
|
||||
|
||||
Como precaución adicional, te recomendamos comparar los balances de tus direcciones emisoras con los fondos de garantía en tu sistema de contabilidad interna en cada nueva versión del ledger del XRP Ledger. Los saldos negativos de la dirección emisora deben coincidir con los activos que has asignado al XRP Ledger fuera de la red. Si ambos no coinciden, deberías suspender el procesamiento de pagos hacia y desde el XRP Ledger hasta que hayas resuelto la discrepancia.
|
||||
|
||||
* Utiliza el método `gateway_balances` para comprobar tus balances.
|
||||
* Si tienes un coste de transferencia (transfer fee) establecido, entonces tus obligaciones dentro del XRP Ledger disminuyen ligeramente cada vez que otras direcciones del XRP Ledger transfieran tus tokens entre sí.
|
||||
|
||||
Para más detalles en cómo se leen los detalles de transacciones entrantes, visita [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md).
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
html: sending-payments-to-customers.html
|
||||
parent: payment-types.html
|
||||
seo:
|
||||
description: Construye los pagos con cuidado para frustrar a los actores maliciosos.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Enviar pagos a clientes
|
||||
|
||||
Cuando construyes un sistema automatizado para enviar pagos al XRP Ledger para tus clientes, debes asegurarte de que construyes los pagos cuidadosamente. Los actores maliciosos están constantemente tratando de encontrar formas de engañar a un sistema para que les pague más dinero del que debería.
|
||||
|
||||
Generalmente, al enviar stablecoins, utilizas una [transacción Payment][]. Algunos detalles son diferentes dependiendo de si estás emitiendo tokens por primera vez o transfiriéndolos desde una cartera activa a un cliente. Cosas a tener en cuenta incluyen:
|
||||
|
||||
- Siempre especifica tu dirección emisora como el emisor del token. De lo contrario, podrías usar accidentalmente rutas (paths) que entreguen la misma divisa emitida por otras direcciones.
|
||||
- Antes de enviar un pago al XRP Ledger, comprueba el coste del pago. Un pago desde tu dirección operacional a un cliente no debe costar más que la cantidad de destino más cualquier coste de transferencia que hayas establecido.
|
||||
- Cuando emites nuevos tokens desde tu dirección emisora, debes omitir el campo `SendMax`. De lo contrario, los usuarios malintencionados pueden configurar sus ajustes para que emitas la cantidad completa de `SendMax` en lugar de solo la `Amount` de destino prevista.
|
||||
- Cuando envías tokens _desde una cartera caliente_, debes especificar `SendMax` si tienes un coste de transferencia distinto de cero. En este caso, establece el campo `SendMax` en la cantidad especificada en el campo `Amount` más el coste de transferencia. (Puede que desees redondear ligeramente hacia arriba, en caso de que la precisión de tus cálculos no coincida exactamente con la del XRP Ledger). Por ejemplo, si envías una transacción cuyo campo `Amount` especifica 99.47 USD, y tu coste de transferencia es del 0.25%, deberías establecer el campo `SendMax` en 124.3375, o 124.34 USD si redondeas hacia arriba.
|
||||
- Omitir el campo `Paths`. Este campo es innecesario cuando se envía directamente desde el emisor, o desde una cartera caliente siempre y cuando los tokens que se envían y los que se reciben tengan el mismo código de divisa y emisor, es decir, sean la misma stablecoin. El campo `Paths` está destinado a [Pagos entre divisas](cross-currency-payments.md) y a pagos multi-salto (rippling) más largos. Si realizas una búsqueda de rutas (paths) de manera ingenua y adjuntas las rutas a tu transacción, tu pago puede tomar un camino indirecto más costoso en lugar de fallar si el camino directo no está disponible; los usuarios malintencionados incluso pueden configurar esto.
|
||||
- Si recibes un código de resultado `tecPATH_DRY`, esto suele indicar que el cliente no tiene configurada la línea de confianza (trustline) necesaria, o que los ajustes de rippling de tu emisor no están configurados correctamente.
|
||||
|
||||
Para un tutorial detallado sobre cómo emitir un token en el XRP Ledger, ya sea una stablecoin u otro tipo, visita [Emitir un token fungible](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md).
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
html: autobridging.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
description: El puente automático conecta automáticamente los libros de órdenes utilizando XRP como intermediario cuando reduce los costes.
|
||||
labels:
|
||||
- XRP
|
||||
- Exchange Descentralizado
|
||||
---
|
||||
# Puente automático
|
||||
|
||||
Cualquier [Oferta](offers.md) en el [exchange descentralizado](index.md) del XRP Ledger que intercambie dos tokens podría potencialmente utilizar XRP como moneda intermediaria en un libro de órdenes sintético. Esto se debe al _puente automático_, que sirve para mejorar la liquidez en todos los pares de activos utilizando XRP cuando es más barato que intercambiar directamente. Esto funciona debido a la naturaleza de XRP como criptomoneda nativa del XRP Ledger. La ejecución de la oferta puede utilizar una combinación de ofertas directas y ofertas auto-puenteadas para lograr la mejor tasa de cambio total.
|
||||
|
||||
Ejemplo: _Anita crea una oferta para vender GBP y comprar BRL. Ella podría encontrar que este mercado poco común tiene pocas ofertas. Hay una oferta con una buena tasa, pero tiene una cantidad insuficiente para satisfacer el intercambio de Anita. Sin embargo, tanto GBP como BRL tienen mercados activos y competitivos para XRP. El sistema de puente automático del XRP Ledger encuentra una forma de completar la oferta de Anita comprando XRP con GBP de un trader, luego vendiendo el XRP a otro trader para comprar BRL. Anita obtiene automáticamente la mejor tasa posible combinando la pequeña oferta en el mercado directo de GBP:BRL con las mejores tasas compuestas creadas emparejando las ofertas GBP:XRP y XRP:BRL._ <!-- SPELLING_IGNORE: gbp -->
|
||||
|
||||
El puente automático ocurre automáticamente en cualquier [transacción OfferCreate][]. Las [transacciones de Payment](../../../references/protocol/transactions/types/payment.md) _no_ usan auto-puente por defecto, pero path-finding pueden encontrar [rutas o paths](../fungible-tokens/paths.md) que tengan el mismo efecto.
|
||||
|
||||
## Ver también
|
||||
|
||||
- [Dev Blog: Introducción al Autopuente](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) <!-- SPELLING_IGNORE: autobridging -->
|
||||
|
||||
- [Preferencia de oferta](offers.md#offer-preference)
|
||||
|
||||
- [Rutas de pago](../fungible-tokens/paths.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
html: automated-market-makers.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
title: ¿Qué es un Automated Market Maker (AMM)?
|
||||
description: Los Automated Market Makers (AMMs) son una parte esencial de las criptomonedas, proveen liquidez entre dos pares de activos. Aprende más sobre AMMs y el XRP Ledger.
|
||||
labels:
|
||||
- XRP
|
||||
- Exchange Descentralizado
|
||||
- AMM
|
||||
---
|
||||
# ¿Qué es un Automated Market Maker (AMM)?
|
||||
|
||||
_(Requiere la [enmienda AMM][] XLS-30)_
|
||||
|
||||
Los Creadores de Mercado Automatizados o Automated Market Maker (AMMs) son contratos inteligentes que proporcionan liquidez en el exchange descentralizado del XRP Ledger. Cada AMM posee un pool de dos activos y permite a los usuarios intercambiar entre ellos a una tasa de cambio establecida por una fórmula.
|
||||
|
||||
Para cualquier par de activos dado, puede haber hasta un AMM en el ledger. Cualquiera puede crear el AMM para un par de activos si aún no existe, o depositar en un AMM existente. Aquellos que depositan activos en un AMM se llaman proveedores de liquidez o _liquidity providers_ (LPs) y reciben "Tokens LP" del AMM. Los Tokens LP permiten a los proveedores de liquidez:
|
||||
|
||||
- Canjear sus Tokens LP por una parte de los activos en el pool del AMM, incluidas las tarifas recolectadas.
|
||||
- Votar para cambiar la configuración de tarifas del AMM. Los votos están ponderados en función de cuántos Tokens LP poseen los votantes.
|
||||
- Pujar con algunos de sus Tokens LP para recibir un descuento temporal en las tarifas de intercambio del AMM.
|
||||
|
||||
Cuando el flujo de fondos entre los dos activos en un pool es relativamente activo y equilibrado, las tarifas proporcionan una fuente de ingresos pasivos para los proveedores de liquidez. Sin embargo, cuando el precio relativo entre los activos cambia, los proveedores de liquidez pueden sufrir una pérdida en el [riesgo de divisa](https://www.investopedia.com/terms/c/currencyrisk.asp).
|
||||
|
||||
## ¿Cómo funciona el AMM?
|
||||
|
||||
Un AMM posee dos activos diferentes: como máximo, uno de estos puede ser XRP, y uno o ambos pueden ser [tokens](../index.md). Los tokens con diferentes emisores se consideran activos diferentes para este propósito. Esto significa que puede haber un AMM para dos tokens con el mismo código de moneda pero diferentes emisores ("FOO emitido por WayGate" es diferente de "FOO emitido por StableFoo"), o el mismo emisor pero diferentes códigos de moneda. El orden no importa; el AMM para FOO.WayGate a XRP es el mismo que para XRP a FOO.WayGate.
|
||||
|
||||
Cuando los usuarios desean comerciar en el exchange descentralizado, sus [Ofertas](offers.md) y [Pagos entre divisas](../../payment-types/cross-currency-payments.md) pueden utilizar automáticamente los AMMs para completar el intercambio. Una sola transacción podría ejecutarse mediante la coincidencia de Ofertas, AMMs o una combinación de ambos, dependiendo de lo que sea más económico.
|
||||
|
||||
Un AMM establece su tasa de cambio en función del saldo de activos en el pool. Cuando intercambias contra un AMM, la tasa de cambio se ajusta según cuánto tu intercambio desequilibre el saldo de activos que el AMM posee. A medida que su suministro de un activo disminuye, el precio de ese activo sube; a medida que su suministro de un activo aumenta, el precio de ese activo baja. Un AMM ofrece tasas de cambio generalmente mejores cuando tiene cantidades más grandes en general en su pool. Esto se debe a que cualquier intercambio dado causa un cambio más pequeño en el equilibrio de los activos del AMM. Cuanto más desequilibre un intercambio el suministro de los dos activos del AMM, más extrema se vuelve la tasa de cambio.
|
||||
|
||||
El AMM también cobra una tarifa de intercambio porcentual además de la tasa de cambio.
|
||||
|
||||
El XRP Ledger implementa un AMM de _media geométrica_ con un parámetro de peso de 0.5, por lo que funciona como un creador de mercado de _producto constante_. Para obtener una explicación detallada de la fórmula AMM de _producto constante_ y la economía de los AMMs en general, consulta [Introducción a los Automated Market Makers de Kris Machowski](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/).
|
||||
|
||||
### Restricciones sobre los activos
|
||||
|
||||
Para evitar el mal uso, se aplican algunas restricciones a los activos utilizados en un AMM. Si intentas crear un AMM con un activo que no cumple con estas restricciones, la transacción falla. Las reglas son las siguientes:
|
||||
|
||||
- El activo no debe ser un Token LP de otro AMM.
|
||||
- Si el activo es un token cuyo emisor utiliza [Authorized Trust Lines](../fungible-tokens/authorized-trust-lines.md), el creador del AMM debe estar autorizado para poseer esos tokens. Solo los usuarios cuyas líneas de confianza (trustlines) estén autorizadas pueden depositar ese token en el AMM o retirarlo; sin embargo, los usuarios aún pueden depositar o retirar el otro activo.
|
||||
- Si la [enmienda Clawback][] está habilitada, el emisor del token no debe haber habilitado la capacidad de recuperar sus tokens.
|
||||
|
||||
|
||||
## Tokens LP
|
||||
<!-- TODO: add diagrams showcasing flow of funds -->
|
||||
Quien crea el AMM se convierte en el primer proveedor de liquidez y recibe Tokens LP que representan el 100% de la propiedad de los activos en el pool del AMM. Pueden canjear algunos o todos esos Tokens LP para retirar activos del AMM en proporción a las cantidades actualmente allí. (Las proporciones cambian con el tiempo a medida que las personas comercian contra el AMM). El AMM no cobra una tarifa al retirar ambos activos.
|
||||
|
||||
Por ejemplo, si creaste un AMM con 5 ETH y 5 USD, y luego alguien cambió 1.26 USD por 1 ETH, el pool ahora tiene 4 ETH y 6.26 USD en él. Puedes gastar la mitad de tus Tokens LP para retirar 2 ETH y 3.13 USD.
|
||||
|
||||
Cualquiera puede depositar activos en un AMM existente. Cuando se hace, se reciben nuevos Tokens LP según lo que depositaron. La cantidad que un proveedor de liquidez puede retirar de un AMM se basa en la proporción de los Tokens LP del AMM que poseen en comparación con el número total de Tokens LP pendientes.
|
||||
|
||||
Los Tokens LP son como otros tokens en el XRP Ledger, por lo que puedes usarlos en muchos [tipos de pagos](../../payment-types/index.md) o intercambiarlos en el exchange descentralizado. (Para recibir Tokens LP como pago, debes configurar una [trust line](../fungible-tokens/index.md) con un límite distinto de cero con la cuenta del AMM como emisor). Sin embargo, _solo_ puedes enviar Tokens LP directamente al AMM (canjeándolos) usando el tipo de transacción [AMMWithdraw][], no a través de otros tipos de pagos. Del mismo modo, solo puedes enviar activos al pool del AMM a través del tipo de transacción [AMMDeposit][].
|
||||
|
||||
El AMM está diseñado de manera que el pool de activos de un AMM esté vacío si y solo si el AMM no tiene Tokens LP pendientes. Esta situación solo puede ocurrir como resultado de una transacción [AMMWithdraw][]; cuando ocurre, el AMM se elimina automáticamente.
|
||||
|
||||
### Códigos de moneda de Tokens LP
|
||||
|
||||
Los Tokens LP utilizan un tipo especial de código de moneda en el formato hexadecimal de 160 bits ["no estándar"](../../../references/protocol/data-types/currency-formats.md#nonstandard-currency-codes). Estos códigos tienen los primeros 8 bits `0x03`. El resto del código es un hash SHA-512, truncado a los primeros 152 bits, de los códigos de moneda de los dos activos y sus emisores. (Los activos se colocan en un "orden canónico" con el par de moneda+emisor numéricamente inferior primero). Como resultado, los Tokens LP para un par de activos dado de un AMM tienen un código de moneda predecible y consistente.
|
||||
|
||||
|
||||
## Tarifas de intercambio
|
||||
|
||||
Las tarifas de intercambio son una fuente de ingresos pasivos para los proveedores de liquidez, y compensan el riesgo cambiario de permitir que otros intercambien activos del pool. Las tarifas de intercambio se pagan al AMM, no directamente a los proveedores de liquidez, pero estos se benefician porque sus Tokens LP se pueden canjear por un porcentaje del pool del AMM.
|
||||
|
||||
Los proveedores de liquidez pueden votar para establecer la tarifa del 0% al 1%, en incrementos de 0.001%. Los proveedores de liquidez tienen un incentivo para establecer las tarifas de intercambio a una tasa adecuada: si las tarifas son demasiado altas, los intercambios usarán libros de pedidos para obtener una mejor tasa; si las tarifas son demasiado bajas, los proveedores de liquidez no obtienen ningún beneficio por contribuir al pool. <!-- STYLE_OVERRIDE: will --> Cada AMM da a sus proveedores de liquidez el poder de votar sobre sus tarifas, en proporción a la cantidad de Tokens LP que poseen esos proveedores de liquidez.
|
||||
|
||||
Para votar, un proveedor de liquidez envía una [transacción AMMVote][]. Cada vez que alguien realiza una nueva votación, el AMM recalcula su tarifa para ser un promedio de las últimas votaciones ponderadas por la cantidad de Tokens LP que poseen esos votantes. Se pueden contar hasta 8 votos de proveedores de liquidez de esta manera; si más proveedores de liquidez intentan votar, solo se contarán los 8 mejores votos (por la mayor cantidad de Tokens LP que poseen). Aunque la participación de los proveedores de liquidez en Tokens LP puede cambiar rápidamente por muchas razones (como el comercio de esos tokens usando [Ofertas](offers.md)), las tarifas de intercambio solo se recalculan cuando alguien realiza una nueva votación (incluso si esa votación no está entre los 8 mejores).
|
||||
|
||||
### Slot de subasta
|
||||
|
||||
A diferencia de cualquier Automated Market Maker anterior, el diseño de AMM del XRP Ledger tiene un _slot de subasta_ en la que un proveedor de liquidez puede pujar para obtener un descuento en la tarifa de intercambio durante un período de 24 horas. La oferta debe pagarse en Tokens LP, que se devuelven al AMM. No más de una cuenta puede tener el slot de subasta al mismo tiempo, pero el ofertante puede nombrar hasta 4 cuentas adicionales para también recibir el descuento. No hay una oferta mínima, pero si el slot está ocupado actualmente, debes superar al titular actual del slot para desplazarlos. Si alguien te desplaza, recuperas parte de tu oferta según el tiempo restante. Mientras mantengas un slot de subasta activo, pagas una tarifa de intercambio con descuento igual a 1/10 (una décima parte) de la tarifa de intercambio normal al realizar operaciones contra ese AMM.
|
||||
|
||||
Con cualquier AMM, cuando el precio de sus activos cambia significativamente en los mercados externos, los traders pueden usar arbitraje para obtener beneficios del AMM, lo que resulta en una pérdida para los proveedores de liquidez. El mecanismo de subasta tiene como objetivo devolver más de ese valor a los proveedores de liquidez y llevar los precios del AMM más rápidamente de vuelta al equilibrio con los mercados externos.
|
||||
|
||||
|
||||
## Representación en el Ledger
|
||||
|
||||
En los datos de estado del ledger, un AMM consiste en múltiples [entradas de ledger](../../../references/protocol/ledger-data/ledger-entry-types/index.md):
|
||||
|
||||
- Una [entrada AMM][] que describe el creador de mercado automatizado en sí mismo.
|
||||
|
||||
- Una [entrada AccountRoot][] especial que emite Tokens LP del AMM, y tiene XRP del AMM (si lo tiene).
|
||||
|
||||
La dirección de esta AccountRoot se elige de forma algo aleatoria cuando se crea el AMM, y es diferente si el AMM se elimina y se vuelve a crear. Esto puede prevenir que las personas financien la cuenta AMM con XRP excesivo por adelantado.
|
||||
|
||||
- Las [Trust lines](../fungible-tokens/index.md) a la cuenta especial AMM para los tokens en el pool del AMM.
|
||||
|
||||
Estas entradas de ledger no son propiedad de ninguna cuenta, por lo que el [requisito de reserva](../../accounts/reserves.md) no se aplica a ellas. Sin embargo, para prevenir el spam, la transacción para crear un AMM tiene un [coste de transacción](../../transactions/transaction-cost.md) especial que requiere que el remitente queme una cantidad de XRP mayor de lo habitual.
|
||||
|
||||
|
||||
## Eliminación
|
||||
|
||||
Un AMM se elimina cuando una [transacción AMMWithdraw][] retira todos los activos de su pool. Esto solo ocurre canjeando todos los Tokens LP pendientes del AMM. La eliminación del AMM incluye la eliminación de todas las entradas del ledger asociadas con él, como:
|
||||
|
||||
- AMM
|
||||
- AccountRoot
|
||||
- Trust lines para los Tokens LP del AMM. Estas trust lines tendrían un saldo de 0 pero pueden tener otros detalles como el límite, establecido en un valor no predeterminado.
|
||||
- Las Trust lines para los tokens que estaban en el pool del AMM.
|
||||
|
||||
Si hay más de 512 trust lines enlazadas a la cuenta del AMM cuando se eliminase, el proceso de retiro tiene éxito y elimina tantas trust lines como puede, pero deja el AMM en el ledger sin activos en su pool.
|
||||
|
||||
Mientras un AMM no tenga activos en su pool, cualquiera puede eliminarlo enviando una [transacción AMMDelete][]; si el número restante de líneas de confianza sigue siendo mayor que el límite, pueden ser necesarias múltiples transacciones AMMDelete para eliminar completamente el AMM. Alternativamente, cualquier persona puede realizar un [depósito especial](../../../references/protocol/transactions/types/ammdeposit.md#empty-amm-special-case) para financiar el AMM como si fuera nuevo.
|
||||
|
||||
No hay reembolso o incentivo para eliminar un AMM vacío.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
html: decentralized-exchange.html
|
||||
parent: tokens.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: El XRP Ledger contiene un exchange completamente funcional donde los usuarios pueden intercambiar tokens por XRP o entre sí.
|
||||
targets:
|
||||
- en
|
||||
---
|
||||
# Exchange descentralizado
|
||||
|
||||
El XRP Ledger posiblemente tenga el _exchange descentralizado_ más antiguo del mundo (a veces abreviado como "DEX"), operando de manera continua desde el lanzamiento del XRP Ledger en 2012. Este exchange permite a los usuarios comprar y vender [tokens](../index.md) por XRP u otros tokens, con [costes](../../transactions/fees.md) mínimos cargados a la red misma (no pagados a ninguna parte).
|
||||
|
||||
**Atención**: Cualquiera puede [emitir un token](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) con el código de moneda o símbolo de ticker que desee y venderlo en el exchange descentralizado. Siempre realiza una debida diligencia antes de comprar un token y presta atención al emisor. De lo contrario, podrías entregar algo de valor y recibir tokens sin valor a cambio.
|
||||
|
||||
## Estructura
|
||||
|
||||
El exchange descentralizado del XRP Ledger consta de un número ilimitado de pares de divisas, rastreados según la demanda cuando los usuarios realizan intercambios. Un par de divisas puede consistir en XRP y un token o dos tokens diferentes; los tokens siempre se identifican por la combinación de un emisor y un código de moneda. Es posible comerciar entre dos tokens con el mismo código de moneda y diferentes emisores, o el mismo emisor y diferentes códigos de moneda. <!-- STYLE_OVERRIDE: limited number -->
|
||||
|
||||
Como con todos los cambios en el XRP Ledger, necesitas enviar una [transacción](../../transactions/index.md) para realizar un intercambio. Un intercambio en el XRP Ledger se conoce como Oferta u [Offer](offers.md). Una Oferta es efectivamente una [_Orden límite_](https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order) para comprar o vender una cantidad específica de una moneda (XRP o un token) por una cantidad específica de otra. Cuando la red ejecuta una Oferta, si hay otras Ofertas coincidentes para el mismo par de divisas, estas se consumen comenzando con la mejor tasa de cambio primero.
|
||||
|
||||
Una Oferta puede llenarse completamente o parcialmente; si no se llena completamente de inmediato, se convierte en un objeto de Oferta pasiva en el ledger para la cantidad restante. Más adelante, otras Ofertas o [pagos entre divisas](../../payment-types/cross-currency-payments.md) pueden coincidir y consumir la Oferta. Debido a esto, las Ofertas pueden ejecutarse a un mejor precio que el solicitado inicialmente, o exactamente al tipo de cambio indicado más tarde (excepto por diferencias menores para tener en cuenta el redondeo).
|
||||
|
||||
Las Ofertas pueden cancelarse manual o automáticamente después de ser colocadas. Para obtener detalles sobre esto y otras propiedades de las Ofertas, consulta [Ofertas](offers.md).
|
||||
|
||||
Al comerciar con dos tokens, el [puente automático](autobridging.md) mejora las tasas de cambio y la liquidez al intercambiar automáticamente token por XRP y XRP por token cuando hacerlo es más barato que intercambiar directamente token por token.
|
||||
|
||||
### Ejemplo de intercambio
|
||||
|
||||
[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.svg" /%}](/docs/img/decentralized-exchange-example-trade.svg "Diagrama: Oferta parcialmente completada para comprar un token con XRP.")
|
||||
|
||||
El diagrama anterior muestra un ejemplo de intercambio en el exchange descentralizado. En este ejemplo, un trader llamado Tran coloca una Oferta para comprar 100 tokens con el código de moneda FOO emitido por un negocio ficticio llamado WayGate. (Por brevedad, "FOO.WayGate" se refiere a estos tokens.) Tran especifica que está dispuesto a gastar hasta 1000 XRP en total. Cuando la transacción de Tran es procesada, ocurren las siguientes cosas:
|
||||
|
||||
1. La red calcula la tasa de cambio de la Oferta de Tran, dividiendo la cantidad a comprar por la cantidad a pagar.
|
||||
0. La red encuentra el libro de órdenes para el reverso de la Oferta de Tran: en este caso, eso significa el libro de órdenes para vender FOO.WayGate y comprar XRP. Este libro de órdenes ya tiene varias Ofertas existentes de otros traders para diferentes cantidades y tasas de cambio.
|
||||
0. La Oferta de Tran "consume" Ofertas coincidentes, comenzando con la mejor tasa de cambio y trabajando hacia abajo, hasta que la Oferta de Tran se haya llenado por completo o no haya más Ofertas cuya tasa de cambio sea igual o mejor que la tasa especificada en la Oferta de Tran. En este ejemplo, solo hay disponibles 22 FOO.WayGate a la tasa solicitada o mejor. Las Ofertas consumidas se eliminan del libro de órdenes.
|
||||
0. Tran recibe la cantidad de FOO.WayGate que el intercambio pudo adquirir, de los varios traders que previamente habían colocado órdenes para venderlo. Estos tokens van a la [trust line](../fungible-tokens/index.md) de Tran a WayGate para FOO. (Si Tran no tenía esa trust line previamente, se crea automáticamente una).
|
||||
0. A cambio, esos traders reciben XRP de Tran de acuerdo con sus tasas de cambio declaradas.
|
||||
0. La red calcula el resto de la Oferta de Tran: dado que la Oferta original era para comprar 100 FOO.WayGate y hasta ahora Tran ha recibido 22, el resto es de 78 FOO.WayGate. Usando la tasa de cambio original, eso significa que el resto de la Oferta de Tran ahora es comprar 78 FOO.WayGate por 780 XRP.
|
||||
0. El "resto" resultante se coloca en el libro de órdenes para intercambios en la misma dirección que la de Tran: vendiendo XRP y comprando FOO.WayGate.
|
||||
|
||||
Las transacciones posteriores, incluidas aquellas ejecutadas inmediatamente después de las de Tran en el _mismo_ ledger, utilizan los libros de órdenes actualizados para sus intercambios, por lo que pueden consumir parte o toda la Oferta de Tran hasta que se llene por completo o Tran la cancele.
|
||||
|
||||
**Nota**: El orden canónico en el que las transacciones se ejecutan cuando se cierra y valida un ledger no es el mismo que el orden en el que se enviaron esas transacciones. Cuando varias transacciones afectan al mismo libro de órdenes en el mismo ledger, los resultados finales de esas transacciones pueden ser muy diferentes a los resultados tentativos calculados en el momento del envío de la transacción. Para obtener más detalles sobre cuándo los resultados de las transacciones son o no finales, consulta [Finalidad de resultados](../../transactions/finality-of-results/index.md).
|
||||
|
||||
|
||||
## Limitaciones
|
||||
|
||||
El exchange descentralizado está diseñado con las siguientes limitaciones:
|
||||
|
||||
Debido a que los intercambios se ejecutan solo cada vez que se cierra un nuevo ledger (aproximadamente cada 3-5 segundos), el XRP Ledger no es adecuado para el [trading de alta frecuencia](https://en.wikipedia.org/wiki/High-frequency_trading). El orden en el que las transacciones se ejecutan dentro de un ledger está diseñado para ser impredecible, para desalentar el [front-running](https://en.wikipedia.org/wiki/Front_running).
|
||||
|
||||
El XRP Ledger no representa nativamente conceptos como órdenes de mercado, órdenes de stop o trading con apalancamiento. Algunos de estos pueden ser posibles con el uso creativo de tokens personalizados y propiedades de Oferta.
|
||||
|
||||
Como sistema descentralizado, el XRP Ledger no tiene información sobre las personas y organizaciones reales detrás de las [cuentas](../../accounts/index.md) involucradas en el trading. El Ledger en sí no puede implementar restricciones sobre quién puede o no puede participar en el trading, y los usuarios y emisores deben tener cuidado de seguir todas las leyes relevantes para regular el trading de tokens que representan varios tipos de activos subyacentes. Funciones como [congelamientos](../fungible-tokens/freezes.md) y [trust lines autorizadas](../fungible-tokens/authorized-trust-lines.md) están destinadas a ayudar a los emisores a cumplir con las leyes y regulaciones relevantes.
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- Ver [Ofetas](offers.md) para obtener detalles sobre cómo funcionan los intercambios en el XRP Ledger.
|
||||
- Ver [Tokens](../index.md) para obtener una descripción general de cómo se pueden representar diversos tipos de valor en el XRP Ledger.
|
||||
- **Referencias:**
|
||||
- [método account_offers][] para buscar Ofertas creadas por una cuenta
|
||||
- [método book_offers][] para buscar Ofertas de compra o venta según un par de divisas dado
|
||||
- [transacción OfferCreate][] para crear una Oferta nueva o reemplazar una Oferta existente
|
||||
- [transacción OfferCancel][] para cancelar una Oferta existente
|
||||
- [objeto Offer][] para la estructura de datos de las Ofertas pasivas en el ledger
|
||||
- [objeto DirectoryNode][] para la estructura de datos que sigue todas las Ofertas para un par de divisas y tarifa de intercambio dados.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
html: offers.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
description: Las ofertas son la forma de órdenes de comercio de divisas del XRP Ledger. Comprende su ciclo de vida y propiedades.
|
||||
labels:
|
||||
- Exchange Descentralizado
|
||||
---
|
||||
# Ofertas
|
||||
|
||||
En el [exchange descentralizado](index.md) del XRP Ledger, las órdenes de intercambio se llaman "Ofertas". Las Ofertas pueden intercambiar XRP con [tokens](../index.md), o tokens por otros tokens, incluyendo tokens con el mismo código de moneda pero diferentes emisores. (Los tokens con el mismo código pero diferentes emisores también a veces pueden intercambiarse a través de [rippling](../fungible-tokens/rippling.md).)
|
||||
|
||||
- Para crear una Oferta, envía una [transacción OfferCreate][].
|
||||
- Las Ofertas que no se completan totalmente inmediatamente se convierten en [objetos Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md) en los datos del ledger. Ofertas posteriores o Pagos pueden consumir el objeto Oferta desde el ledger.
|
||||
- [Pagos entre divisas](../../payment-types/cross-currency-payments.md) consumen Ofertas para proveer liquidez, nunca crean objetos de Oferta en el ledger.
|
||||
|
||||
## Ciclo de vida para una Oferta
|
||||
|
||||
Una [transacción OfferCreate][] es una instrucción para realizar un intercambio, ya sea entre dos tokens, o un token y XRP. Cada transacción de este tipo contiene una cantidad de compra (`TakerPays`) y una cantidad de venta (`TakerGets`). Cuando se procesa la transacción, consume automáticamente Ofertas coincidentes o cruzadas en la medida de lo posible. Si eso no llena completamente la nueva Oferta, entonces el resto se convierte en un objeto de Oferta en el ledger.
|
||||
|
||||
El objeto de Oferta espera en el ledger hasta que otras Ofertas o pagos entre divisas lo consumen completamente. La cuenta que colocó la Oferta se llama el _propietario_ de la Oferta. Puedes cancelar tus propias Ofertas en cualquier momento, usando la [transacción OfferCancel][] dedicada, o como opción de la [transacción OfferCreate][].
|
||||
|
||||
Mientras tengas una Oferta en el ledger, se aparta parte de tu XRP hacia la [reserva de propietario](../../accounts/reserves.md). Cuando se elimina la Oferta, por cualquier motivo, ese XRP se libera nuevamente.
|
||||
|
||||
### Variaciones
|
||||
|
||||
- **Compra vs. Venta**: Por defecto, las Ofertas son Ofertas de "compra" y se consideran completamente llenas cuando has adquirido la cantidad total de "compra" (`TakerPays`). (Puedes gastar menos de lo esperado mientras recibes la cantidad especificada.) En contraste, una Oferta de "venta" solo se considera completamente llena cuando has gastado la cantidad total de "venta" (`TakerGets`). (Puedes recibir más de lo esperado mientras gastas la cantidad especificada.) Esto solo es relevante si la Oferta se ejecuta _inicialmente_ a un tipo de cambio mejor que el solicitado: después de que la Oferta se coloca en el ledger, solo se ejecuta _exactamente_ al tipo de cambio solicitado.
|
||||
- Una Oferta **Inmediata o Cancelar** no se coloca en el ledger, por lo que solo intercambia hasta la cantidad que coincide con Ofertas existentes en el momento en que se procesa la transacción.
|
||||
- Una Oferta **Completar o Cancelar** no se coloca en el ledger, _y_ se cancela si la cantidad total no se completa cuando se ejecuta inicialmente. Esto es similar a "Inmediata o Cancelar", excepto que _no puede_ completarse parcialmente.
|
||||
- Una Oferta **Pasiva** no consume Ofertas coincidentes que tengan el mismo tipo de cambio (en la otra dirección), y en su lugar se coloca directamente en el ledger. Puedes usar esto para crear un peg exacto entre dos activos. Las Ofertas Pasivas aún consumen otras Ofertas que tienen un tipo de cambio _mejor_ en la otra dirección.
|
||||
|
||||
|
||||
### Requisitos de financiación
|
||||
|
||||
Cuando intentas realizar una Oferta, la transacción se rechaza como "no financiada" si no tienes al menos parte del activo que la operación vendería. Más específicamente:
|
||||
|
||||
**Para vender un token,** debes:
|
||||
|
||||
- Tener una cantidad positiva de ese token, _o_
|
||||
- Ser el emisor del token.
|
||||
|
||||
Sin embargo, no necesitas tener la cantidad completa especificada en la Oferta. Colocar una Oferta no bloquea tus fondos, por lo que puedes colocar múltiples Ofertas para vender los mismos tokens (o XRP), o colocar una Oferta y esperar obtener suficientes tokens o XRP para financiarla completamente más adelante.
|
||||
|
||||
**Para vender XRP**, debes tener suficiente XRP para cumplir con todos los [requisitos de reserva](../../accounts/reserves.md), incluida la reserva para que el objeto de Oferta se coloque en el ledger y para la trust line para mantener el token que estás comprando. Mientras tengas XRP restante después de apartar la cantidad de reserva, puedes colocar la Oferta.
|
||||
|
||||
Cuando otra Oferta coincide con la tuya, ambas Ofertas se ejecutan en la medida en que los fondos de sus propietarios lo permitan en ese momento. Si hay Ofertas coincidentes y te quedas sin fondos antes de que la tuya se finalice por completo, el resto de tu Oferta se cancela. Una Oferta no puede hacer que tu saldo de un token sea negativo, a menos que seas el emisor de ese token. (Si eres el emisor, puedes usar Ofertas para emitir nuevos tokens hasta el monto total especificado en tus Ofertas; los tokens que emites se representan como saldos negativos desde tu perspectiva.)
|
||||
|
||||
Si colocas una Oferta que cruza alguna de tus propias Ofertas que existen en el ledger, las Ofertas antiguas cruzadas se cancelan automáticamente independientemente de las cantidades involucradas.
|
||||
|
||||
Es posible que una Oferta se vuelva temporal o permanentemente _no financiada_ en los siguientes casos:
|
||||
|
||||
- Si el propietario ya no tiene ningún activo de venta.
|
||||
- La Oferta se vuelve financiada nuevamente cuando el propietario obtiene más de ese activo.
|
||||
- Si el activo en venta es un token en una [trust line congelada](../fungible-tokens/freezes.md).
|
||||
- La Oferta se vuelve financiada nuevamente cuando la trust line ya no está congelada.
|
||||
- Si la Oferta necesita crear una nueva trust line, pero el dueño no tiene suficiente XRP para el aumento de la [reserva](../../accounts/reserves.md). (Ver [Ofertas y confianza](#offers-and-trust).)
|
||||
- La oferta vuelve a estar financiada cuando el propietario obtiene más XRP, o los requisitos de reserva disminuyen.
|
||||
- Si la Oferta ha expirado. (Ver [Expiración de ofertas](#offer-expiration).)
|
||||
|
||||
Una Oferta no financiada permanece en el ledger hasta que una transacción la elimine. Las formas en que una Oferta puede ser eliminada del ledger incluyen:
|
||||
|
||||
- Una Oferta coincidente o [Pago entre divisas](../../payment-types/cross-currency-payments.md) que consuman completamente la Oferta.
|
||||
- El propietario cancela explicitamente la Oferta.
|
||||
- El propietario cancela implícitamente la Oferta enviando una nueva Oferta que la cruza.
|
||||
- La Oferta es encontrada sin financiar o expirada durante el procesamiento de la transacción. Normalmente esto significa que otra Oferta intentó consumirla y no pudo hacerlo.
|
||||
- Esto incluye casos donde la cantidad restante puede ser pagada mediante la Oferta redondeada a cero.
|
||||
|
||||
### Seguimiento de ofertas no financiadas
|
||||
|
||||
Seguir el estado de financiación de todas las Ofertas puede ser computacionalmente exigente. En particular, las direcciones que están operando activamente pueden tener un gran número de Ofertas abiertas. Un solo balance puede afectar el estado de financiación de muchas Ofertas. Debido a esto, el XRP Ledger no encuentra y elimina _proactivamente_ Ofertas no financiadas o expiradas.
|
||||
|
||||
Una aplicación de cliente puede seguir localmente el estado de financiación de las Ofertas. Para hacerlo, primero recupera un libro de órdenes utilizando el [método book_offers][] y verifica el campo `taker_gets_funded` de las Ofertas. Luego, [suscríbete](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md) al flujo de `transactions` y observa los metadatos de transacción para ver qué Ofertas se modifican.
|
||||
|
||||
|
||||
## Ofertas y confianza
|
||||
|
||||
Los valores límite de las [trust lines](../fungible-tokens/index.md) no afectan a las Ofertas. En otras palabras, puedes usar una Oferta para adquirir más de la cantidad máxima en la que confías en un emisor.
|
||||
|
||||
Sin embargo, mantener tokens aún requiere una trust line con el emisor. Cuando una Oferta se consume, automáticamente crea cualquier trust line necesaria, estableciendo sus límites en 0. Debido a que [las trust lines aumentan la reserva que una cuenta debe mantener](../../accounts/reserves.md), cualquier Oferta que requiera una nueva trust line también requiere que la dirección tenga suficiente XRP para cumplir con la reserva de esa trust line.
|
||||
|
||||
Los límites de la trust line te protegen de recibir más de un token como pago de lo que deseas. Las Ofertas pueden superar esos límites porque son una declaración explícita de cuánto del token deseas.
|
||||
|
||||
|
||||
## Preferencia de Oferta
|
||||
|
||||
Las Ofertas existentes se agrupan por tipo de cambio, que se mide como la relación entre `TakerGets` y `TakerPays`. Las Ofertas con un tipo de cambio más alto se toman preferentemente. (Es decir, la persona que acepta la oferta recibe tanto como sea posible por la cantidad de moneda que paga). Las Ofertas con el mismo tipo de cambio se toman en función de cuál se colocó primero.
|
||||
|
||||
Cuando las Ofertas se ejecutan en el mismo bloque del ledger, el orden en que se ejecutan se determina por el [orden canónico](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Código fuente: Ordenación de transacciones") en el que las transacciones fueron [aplicadas en el ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Código fuente: Aplicando transacciones"). Este comportamiento está diseñado para ser determinista, eficiente y difícil de manipular.
|
||||
|
||||
|
||||
## Caducidad de la oferta
|
||||
|
||||
Cuando colocas una Oferta, puedes opcionalmente añadirle un tiempo de caducidad. Por defecto, las Ofertas no caducan. No puedes crear una nueva Oferta que ya esté caducada.
|
||||
|
||||
Los tiempos de caducidad se especifican hasta el segundo, pero el momento exacto en el que una Oferta caduca en el mundo real es menos preciso. Una Oferta caduca si tiene una hora de caducidad que es _anterior o igual al_ momento de cierre del ledger anterior. De lo contrario, la Oferta aún puede ejecutarse, incluso si el momento real es posterior a la caducidad de la Oferta. En otras palabras, una Oferta sigue "activa" si su hora de caducidad es posterior al momento de cierre del último ledger validado, independientemente de lo que diga tu reloj.
|
||||
|
||||
Esto es una consecuencia de cómo la red alcanza un acuerdo. Para que toda la red peer-to-peer alcance un consenso, todos los servidores deben estar de acuerdo en qué Ofertas han caducado al ejecutar transacciones. Los servidores individuales pueden tener pequeñas diferencias en su configuración interna de reloj, por lo que podrían no llegar a las mismas conclusiones sobre qué Ofertas han caducado si cada uno usara el tiempo "actual". El momento de cierre de un ledger no se conoce hasta después de que las transacciones en ese ledger se hayan ejecutado, por lo que los servidores utilizan el momento oficial de cierre del ledger _anterior_ en su lugar. Los [tiempos de cierre de los ledgers se redondean](../../ledgers/ledger-close-times.md), lo que aumenta aún más la diferencia potencial entre el tiempo real y el tiempo utilizado para determinar si una Oferta ha caducado.
|
||||
|
||||
**Nota:** Las Ofertas caducadas permanecen en los datos del ledger hasta que una transacción las elimine. Hasta entonces, pueden continuar apareciendo en los datos recuperados a través de la API (por ejemplo, utilizando el [método ledger_entry][]). Las transacciones eliminan automáticamente cualquier Oferta caducada y no financiada que encuentren, generalmente mientras ejecutan Ofertas o pagos de monedas cruzadas que las hubieran igualado o cancelado. La reserva del propietario asociada con una Oferta solo vuelve a estar disponible cuando la Oferta se elimina realmente.
|
||||
|
||||
|
||||
## Ver también
|
||||
|
||||
- **Conceptos:**
|
||||
- [Tokens](../index.md)
|
||||
- [Paths](../fungible-tokens/paths.md)
|
||||
- **Referencias:**
|
||||
- [método account_offers][]
|
||||
- [método book_offers][]
|
||||
- [transacción OfferCreate][]
|
||||
- [transacción OfferCancel][]
|
||||
- [Objeto Offer](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
html: ticksize.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
description: Los emisores pueden establecer tamaños de ticks personalizados para las monedas para reducir la rotación de libros de pedidos por diferencias minúsculas en los tipos de cambio.
|
||||
labels:
|
||||
- Exchange Descentralizado
|
||||
- Tokens
|
||||
---
|
||||
# Tamaño de Tick
|
||||
|
||||
Cuando se coloca una Oferta en un libro de órdenes, su tasa de cambio se trunca en base a los valores de `TickSize` establecidos por los emisores de las monedas involucradas en la Oferta. Cuando se negocia XRP y un token, se aplica el `TickSize` del emisor del token. Cuando se negocian dos tokens, la Oferta utiliza el valor de `TickSize` más pequeño (es decir, el que tiene menos dígitos significativos). Si ninguno de los tokens tiene un `TickSize` establecido, se aplica el comportamiento predeterminado.
|
||||
|
||||
El valor de `TickSize` trunca la cantidad de _dígitos significativos_ en la tasa de cambio de una oferta cuando se coloca en un libro de órdenes. Los emisores pueden establecer `TickSize` como un número entero de `3` a `15` usando una [transacción AccountSet][]. La tasa de cambio se representa como dígitos significativos y un exponente; el `TickSize` no afecta al exponente. Esto permite que el XRP Ledger represente tasas de cambio entre activos que varían considerablemente en valor (por ejemplo, una moneda altamente inflada en comparación con un activo raro). Cuanto menor sea el `TickSize` que establezca un emisor, mayor será el incremento que los traders deben ofrecer para considerarse una tasa de cambio más alta que las Ofertas existentes.
|
||||
|
||||
El `TickSize` no afecta a la parte de una Oferta que se puede ejecutar inmediatamente. (Por esa razón, las transacciones OfferCreate con `tfImmediateOrCancel` no se ven afectadas por los valores de `TickSize`.) Si la Oferta no puede ejecutarse completamente, el motor de procesamiento de transacciones calcula la tasa de cambio y la trunca en base a `TickSize`. Luego, el motor redondea la cantidad restante de la Oferta desde el lado "menos importante" para que coincida con la tasa de cambio truncada. Para una transacción OfferCreate predeterminada (una Oferta de "compra"), la cantidad de `TakerPays` (la cantidad que se compra) se redondea. Si se activa la bandera `tfSell` (una Oferta de "venta"), la cantidad de `TakerGets` (la cantidad que se vende) se redondea.
|
||||
|
||||
Cuando un emisor habilita, deshabilita o cambia el `TickSize`, las Ofertas que se colocaron bajo la configuración anterior no se ven afectadas.
|
||||
|
||||
## Ver también
|
||||
|
||||
- [Dev Blog: Introducción a la enmienda TickSize](https://xrpl.org/blog/2017/ticksize-voting.html#ticksize-amendment-overview)
|
||||
- **Referencias:**
|
||||
- [transacción AccountSet][]
|
||||
- [método book_offers][]
|
||||
- [transacción OfferCreate][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
49
@i18n/es-ES/docs/introduction/crypto-wallets.md
Normal file
49
@i18n/es-ES/docs/introduction/crypto-wallets.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
html: crypto-wallets.html
|
||||
parent: intro-to-xrpl.html
|
||||
seo:
|
||||
description: Las carteras brindan una forma conveniente de administrar tu XRP en el XRP Ledger.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Carteras cripto
|
||||
|
||||
Las carteras cripto brindan una forma de administrar tu cuenta y tus fondos en el XRP Ledger. Hay muchas carteras para elegir. Al final, elegir la cartera adecuada se reduce a tus necesidades y a tus gustos al trabajar con XRP.
|
||||
|
||||
|
||||
## Carteras con custodia vs carteras sin custodia
|
||||
|
||||
Un factor importante cuando se elige una cartera es si se desea que sea una cartera con custodia o sin custodia.
|
||||
|
||||
Una cartera con custodia significa que un tercero tiene tus fondos, normalmente en una cuenta que ellos manejan en el XRP Ledger. Una cartera con custodia puede considerarse como un banco, donde confias que otra entidad mantenga tu dinero seguro. Muchos exchanges centralizados ofrecen carteras con custodia, por lo que cuando creas una cuenta con ellos y usas su app, técnicamente no tienes una cuenta en el libro contable (ledger).
|
||||
|
||||
Para los pagos del día a día, esto puede ser preferible, ya que este tipo de carteras son fáciles de usar: si te olvidas de tu contraseña, puedes resetearla. Además, si no tienes una cuenta propia en el XRP Ledger, el requisito de tener una reserva en la cuenta no te aplica. El custodio actua como intermediario ante cualquier problema que encuentres en el XRP Ledger, y puede ofrecerte asistencia si no estás seguro de como hacer algo.
|
||||
|
||||
|
||||
|
||||
Una cartera sin custodia, como [XUMM](https://xumm.app/), es aquella donde tienes las claves secretas (secret keys) de tu cuenta. Esto significa que eres el último reponsable de la administración de la seguridad de tu cuenta.
|
||||
|
||||
**Atención:** Si pierdes tus claves, perderás el acceso a tu cuenta del XRP Ledger y no hay opciones de recupereación.
|
||||
|
||||
Las carteras sin custodia te permiten tener más libertad. Como estás interactuando directamente con el XRP LEdger, puedes manejar cualquier tipo de transacción que tu quieras sin que nadie restrinja tus opciones. Si el libro contable (ledger) lo permite, lo puedes hacer. Las carteras sin custodia no requieren confiar tu dinero a una institución, lo que permite alejarte de los factores del mercado fuera de tu control.
|
||||
|
||||
Tanto los usuarios de carteras con custodia como los usuarios de carteras sin custodia deben protegerse de usuarios malintencionados que podrían intentar robar tus fondos. Con una cartera con custodia, debes administrar tu nombre de usuario y contraseña en la app o en el sitio web; en una cartera sin custodia, tienes que administrar las claves secretas (secrect keys) de tu cuenta en el libro contable (ledger). En ambos casos, las prácticas de seguridad propias del proveedor de la cartera también son importantes para protegerte de vulnerabilidades como ataques a la cadena de suministro, donde un atacante carga código malicioso en la cartera a través de actualizaciones o dependencias. Sin embargo, las carteras con custodia pueden ser un objetivo mayor para los atacantes, ya que tienen acceso inmediato a los fondos de múltiples usuarios.
|
||||
|
||||
|
||||
## Carteras de software vs Carteras de hardware
|
||||
|
||||
Otro factor decisivo a la hora de elegir una cartera es elegir entre una cartera de hardware o de software.
|
||||
|
||||
Las carteras de hardware son dispositivos físicos que almacenan tus claves privadas/secretas. El beneficio principal de usar carteras de hardware es que puedes proteger tu información desconectándola de Internet cuando no se esté usando; Las carteras de hardware aíslan totalmente sus claves de ordenadores y teléfonos inteligentes más faciles de hackear.
|
||||
|
||||
|
||||
|
||||
Las carteras de software por el otro lado, son completamente digitales. Mientras esto las hace mucho más fáciles, también las convierte en el método menos seguro de los dos, pero generalmente vienen con funciones adicionales para mejorar la experiencia. Como última instancia, la decisión entre las dos dependerá de tu nivel de comidad y de lo importante que sea para ti la facilidad de uso.
|
||||
|
||||
|
||||
## Crear tu propia cartera
|
||||
|
||||
El XRP Ledger es un proyecto de código abierto con librerías de cliente y métodos API disponibles públicamente. Si bien técnicamente se puede interactuar con el ledger utilizando herramientas HTTP/WebSocket, no es práctico para el uso del día a día. Puedes crear tu propia cartera para interactuar con el ledger, pero necesitarás entender exáctamente cómo funcionan las cuentas, transacciones y el ledger juntas antes de comprometerte con esta opción.
|
||||
|
||||
|
||||
Siguiente: [Transacciones y peticiones](transactions-and-requests.md)
|
||||
12
@i18n/es-ES/docs/introduction/index.md
Normal file
12
@i18n/es-ES/docs/introduction/index.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
html: introduction.html
|
||||
parent: docs.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
top_nav_grouping: Article Types
|
||||
---
|
||||
# Introducción
|
||||
|
||||
El XRP Ledger es una blockchain que permanentemente registra transacciones digitales de tokens entre cuentas. Las secciones de abajo amplian los conceptos introducidos en esa frase.
|
||||
|
||||
{% child-pages /%}
|
||||
66
@i18n/es-ES/docs/introduction/software-ecosystem.md
Normal file
66
@i18n/es-ES/docs/introduction/software-ecosystem.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
html: software-ecosystem.html
|
||||
parent: introduction.html
|
||||
seo:
|
||||
description: Obtén una descripción general de qué es el software XRP Ledger disponible y como funciona en conjunto.
|
||||
labels:
|
||||
- Servidor central
|
||||
---
|
||||
# Ecosistema software
|
||||
|
||||
El XRP Ledger alberga un ecosistema profundo de varias capas de proyectos de software que impulsan y permiten el Internet del Valor. Es imposible listar cada proyecto, herramienta, y negocio que interactua con el XRP Ledger, asi que esta página solo lista algunas categorías y destaca algunos proyectos centrales que están documentados en este sitio web.
|
||||
|
||||
|
||||
## Niveles de stack
|
||||
|
||||
- [_Servidores Principales](#servidores-principales) forman la base del XRP Ledger, una red peer-to-peer que transmite y procesa transacciones en todo momento.
|
||||
|
||||
- [_Librerías de cliente_](#librerías-cliente) existen en software de alto nivel, donde se importan directamente al código del programa, y contiene métodos para acceder al XRP Ledger.
|
||||
|
||||
- [_Middleware_](#middleware) proporciona acceso indirecto a los datos del XRP Ledger. Las aplicaciones en esta capa suelen tener su propio almacenamiento y procesamiento de datos.
|
||||
|
||||
- [_Apps y servicios_](#apps-y-servicios) proporcionan interación con el XRP Ledger a nivel usuario, o proporcionan una base para aplicaciones y servicios de aun más alto nivel.
|
||||
|
||||
|
||||
### Servidores principales
|
||||
|
||||
La red peer-to-peer en el corazón del XRP Ledger requiere de un servidor altamente confiable y eficiente para hacer cumplir las reglas de consenso y el procesamiento de las transacciones. La Fundación XRP Ledger publica una implementación de referencia de este software de sevidor, llamada [**`rippled`**](../concepts/networks-and-servers/index.md) (pronunciado en inglés como "ripple-dee"). El servidor está disponible bajo [una licencia permisiva de código abierto](https://github.com/XRPLF/rippled/blob/develop/LICENSE.md), por lo que cualquiera puede inspeccionar y modificar su propia instancia del servidor, y volver a publicar con pocas restricciones.
|
||||
|
||||
|
||||
|
||||
Cada servidor central sincroniza con la misma red (a no ser que esté configurado para seguir una [red de test](../concepts/networks-and-servers/parallel-networks.md)) y tiene acceso a todas las comunicaciones a través de la red. Cada servidor de la red guarda una copia completa de lod datos de estado para todo el XRP Ledger, junto con transacciones recientes y un registro de los cambios que esas transacciones han realizado, y cada servidor procesa cada transacción independientemente mientras verifican que el resultado coincide con el resto de la red. Los servidores pueden ser configurados para mantener más [histórico del ledger](../concepts/networks-and-servers/ledger-history.md) y para participar en el proceso de consenso como un [validador](../concepts/networks-and-servers/rippled-server-modes.md#validators).
|
||||
|
||||
Los servidores Core exponen [APIs HTTP / WebSocket](../references/http-websocket-apis/index.md) para que los usuarios busquen datos, administren el servidor, y envíen transacciones. Algunos servidores también ofrecen APIs HTTP / WebSocket pero no conectan directamente con la red peer-to-peer y no procesan transacciones ni participan en el consenso. Estos servidores, como servidores `rippled` ejecutan en modo Reporting y servidores Clio, que dependen de un servidor central en modo P2P para procesar las transacciones.
|
||||
|
||||
|
||||
### Librerías cliente
|
||||
|
||||
Las librerias simplifican parte del trabajo básico de acceder al XRP Ledger, normalmente a través de las APIs HTTP / WebSocket. Convierten los datos en formas que son más familiares y convenientes para varios lenguajes de programación e incluyen implementaiones de operaciones básicas.
|
||||
|
||||
|
||||
|
||||
Una característica prinicpal de la mayoría de las librerías cliente es la firma de transacciones localmente, así los usuarios no tienen que enviar sus claves privadas a través de la red.
|
||||
|
||||
Muchos servicios middleware utilizan librerías cliente internamente.
|
||||
|
||||
Ver [Librerías Cliente](../references/client-libraries.md) para más información sobre las librerías cliente disponibles actualmente.
|
||||
|
||||
|
||||
### Middleware
|
||||
|
||||
Los servicios middleware son programas que consumen las APIs del XRP Ledger por un lado y proporcionan sus propias APIs por el otro. Porporcionan una capa de abstracción para facilitar la creación de aplicaciones a mayor nivel proporcionando funcionalidades comunes como servicios.
|
||||
|
||||
|
||||
|
||||
A diferencia de las librerías cliente, en donde se crean instancias nuevas y se cierran con el programa que las importa, los servicios middleware generalmente permanecen ejecutándose indefinidamente y pueden tener sus propias bases de datos (bases de datos relacionales SQL o de otro tipo) y archivos de configuración. Algunos están disponibles como servicios en la nube con varios precios o limitaciones de uso.
|
||||
|
||||
|
||||
### Apps y servicios
|
||||
|
||||
En lo alto del stack es donde suceden las cosas realmente interesantes. Las apps y servicios ofrecen una forma para que usuarios y dispositivos se conecten al XRP Ledger. Los servicios como los exchanges privados, los acuñadores de tokens, marketplaces, interfaces al exchanges descentralizado, y carteras brindan interfaces de usuario para comprar, vender y comerciar varios activos incluyendo XRP y tokens de todo tipo. Existen muchas otras posibilidades, incluyendo servicios adicionales en capas superiores.
|
||||
|
||||
|
||||
|
||||
Ver [Casos de uso](../use-cases/index.md) para más ejemplos que pueden ser construidos en o encima de esta capa.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
115
@i18n/es-ES/docs/introduction/transactions-and-requests.md
Normal file
115
@i18n/es-ES/docs/introduction/transactions-and-requests.md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
html: txn-and-requests.html
|
||||
parent: intro-to-xrpl.html
|
||||
seo:
|
||||
description: Todas las interacciones con el ledger son transacciones o solicitudes.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
|
||||
## Transacciones y solicitudes
|
||||
|
||||
La mayoría de interacciones con el XRP Ledger implican enviar una transacción que realiza cambios en el ledger o enviar una solicitud de información al ledger. También puedes subscribirte para monitorear constantemente notificaciones de interés.
|
||||
|
||||
## ¿Cómo funcionan las transacciones?
|
||||
|
||||
Utiliza las transacciones para realizar cambios en el ledger, como transferir XRP y otros tokens entre cuentas; acuñar (minting) y quemar (burn) NFTs; y crear, aceptar y cancelar ofertas. Para ejecutar una transacción, envías un comando al XRP Ledger y esperas la confirmación de que la transacción se ha completado. El formato de sintaxis del comando es el mismo para cada transacción.
|
||||
|
||||
- Siempre debes proporcionar el _TransactionType_ y la dirección pública de la _Account_ que realiza la transacción.
|
||||
|
||||
- Dos campos obligatorios son la _Fee_ (comisión) de la transacción y el siguiente número de la _Sequence_ (secuencia) para las transacciones de la cuenta. Estos campos se pueden completar automáticamente.
|
||||
|
||||
- Las transacciones también pueden tener campos obligatorios específicos del tipo de transacción. Por ejemplo, una transacción _Payment_ requiere un valor (cantidad) _Amount_ (en _drops_, o millonésimas de un XRP) y una dirección pública _Destination_ (destino) donde los fondos son acreditados.
|
||||
|
||||
Aquí hay un ejemplo de transacción en formato JSON. Esta transacción transfiere 1 XRP de la cuenta _rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn_ a la cuenta destino _ra5nK24KXen9AHvsdFTKHSANinZseWnPcX_.
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Payment",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": "1000000",
|
||||
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
|
||||
}
|
||||
```
|
||||
|
||||
Hay campos opcionales disponibles para todas las transacciones, con campos adicionales disponibles para transacciones específicas. Puedes incluir tantos campos opcionales como necsites, pero no es necesario incluir todos los campos en cada transacción.
|
||||
|
||||
Puedes enviar la transacción al ledger como un comando de JavaScript, Python, línea de comandos, o cualquier servicio compatible. Los servidores rippled proponen las transacciones al XRPL.
|
||||
|
||||
|
||||
|
||||
Cuando el 80% de los validadores aprueban un conjunto actual de transacciones propuestas, se registran como parte del ledger permanente. Los servidores rippled devuelven los resultados de la transacción que enviaste.
|
||||
|
||||
Para más información sobre Transacciones, ver [Transacciones](../concepts/transactions/index.md).
|
||||
|
||||
## ¿Cómo funcionan las solicitudes?
|
||||
|
||||
Las solicitudes son utilizadas para obtener información del ledger, pero no realizan cambios en el ledger. La información está disponible para cualquiera que quiera consultarla, por lo que no hay necesidad de iniciar sesión con la información de tu cuenta.
|
||||
|
||||
Los campos que envías pueden variar según el tipo de información que solicitas. Normalmente tienen varios campos opcionales, pero solo unos pocos son campos obligatorios.
|
||||
|
||||
Cuando envías tu solicitud, puede ser procesada por un servidor rippled o por un servidor Clio, un servidor dedicado para responder solicitudes.
|
||||
|
||||
|
||||
|
||||
Los servidores Clio quitan parte de la carga a los servidores rippled en el XRPL para mejorar la velocidad de procesamiento y la confiabilidad.
|
||||
|
||||
Esto es un ejemplo de solicitud en formato JSON. Esta solicitud obtiene la información de la cuenta actual para el número de cuenta que facilitas.
|
||||
|
||||
```json
|
||||
{
|
||||
"command": "account_info",
|
||||
"account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn"
|
||||
}
|
||||
```
|
||||
|
||||
La solicitud devuelve una gran cantidad de información. Aquí hay un ejemplo de respuesta para la información de la cuenta solicitada en formato JSON.
|
||||
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
|
||||
"Balance": "999999999960",
|
||||
"Flags": 8388608,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 0,
|
||||
"PreviousTxnID": "4294BEBE5B569A18C0A2702387C9B1E7146DC3A5850C1E87204951C6FDAA4C42",
|
||||
"PreviousTxnLgrSeq": 3,
|
||||
"Sequence": 6,
|
||||
"index": "92FA6A9FC8EA6018D5D16532D7795C91BFB0831355BDFDA177E86C8BF997985F"
|
||||
},
|
||||
"ledger_current_index": 4,
|
||||
"queue_data": {
|
||||
"auth_change_queued": true,
|
||||
"highest_sequence": 10,
|
||||
"lowest_sequence": 6,
|
||||
"max_spend_drops_total": "500",
|
||||
"transactions": [
|
||||
{
|
||||
"auth_change": false,
|
||||
"fee": "100",
|
||||
"fee_level": "2560",
|
||||
"max_spend_drops": "100",
|
||||
"seq": 6
|
||||
},
|
||||
... (recortado por la longitud) ...
|
||||
{
|
||||
"LastLedgerSequence": 10,
|
||||
"auth_change": true,
|
||||
"fee": "100",
|
||||
"fee_level": "2560",
|
||||
"max_spend_drops": "100",
|
||||
"seq": 10
|
||||
}
|
||||
],
|
||||
"txn_count": 5
|
||||
},
|
||||
"status": "success",
|
||||
"validated": false
|
||||
}
|
||||
}
|
||||
```
|
||||
Para obtener información sobre los campos de un registro de información de una cuenta, ver [Cuentas](../concepts/accounts/index.md).
|
||||
|
||||
Siguiente: [Ecosistema de software](software-ecosystem.md)
|
||||
70
@i18n/es-ES/docs/introduction/what-is-the-xrp-ledger.md
Normal file
70
@i18n/es-ES/docs/introduction/what-is-the-xrp-ledger.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
html: what-is-the-xrp-ledger.html
|
||||
parent: introduction.html
|
||||
seo:
|
||||
description: Aprende sobre la blockchain XRP Ledger (XRPL).
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# ¿Qué es el XRP Ledger?
|
||||
|
||||
El XRP Ledger es una blockchain descentralizada que usa su propia moneda digital para procesar y registrar transacciones financieras.
|
||||
|
||||
|
||||
## ¿Qué es una blockchain?
|
||||
|
||||
Una blockchain es una lista de registros en continuo creciemiento. La blockchain comienza con un bloque de datos.
|
||||
|
||||
|
||||
|
||||
Un grupo de nodos validadores confiables llega a un consenso de que los datos son válidos.
|
||||
|
||||
|
||||
|
||||
El bloque se identifica de forma única con un número hash criptográfico, muy elaborado, complejo, generado por un ordenador, que tiene 64 caracteres hexadecimales.
|
||||
|
||||
|
||||
|
||||
El bloque también se identifica con una marca de tiempo (timestamp) con su hora de creación.
|
||||
|
||||
|
||||
|
||||
Cada nodo validador obtiene su propia copia del bloque de datos. No existe una única autoridad central. Todas las copias son igualmente válidas.
|
||||
|
||||
|
||||
|
||||
Cada bloque contiene un puntero hash como enlace al bloque anterior. También tiene una marca de tiempo (timestamp), nuevos datos, y su propio número hash único.
|
||||
|
||||
|
||||
|
||||
Utilizando esta estructura, cada bloque tiene una posición clara en la cadena, enlazandose al bloque de datos anterior. Esto crea una cadena de bloques inmutable. Siempre puedes verificar toda la información actual en la cadena rastreando los bloques anteriores.
|
||||
|
||||
|
||||
|
||||
Por diseño, las blockchains son resistentes a la modificación de datos. Cada nodo del libro contable (ledger) obtiene una copia exacta de la blockchain.
|
||||
|
||||
|
||||
|
||||
Esto crea un libro contable (ledger) abierto y distribuido que registra las transacciones entre partes de manera eficiente, verificable y permanente.
|
||||
|
||||
Una vez registrados, los datos de cualquier bloque no se pueden modificar retroactivamente, a no ser que la mayoría de validadores se pongan de acuerdo en el cambio. Si es así, todo los bloques posteriores se modifican de la misma manera (un hecho muy raro y extremo).
|
||||
|
||||
### ¿Cómo funciona el proceso de consenso federado?
|
||||
|
||||
La mayoría de los servidores rippled en XRPL monitorean o proponen transacciones. Un importante subconjunto de servidores se ejecutan como validadores. Estos servidores confiables acumulan listas de nuevas transacciones en una nueva posible instancia del libro contable (ledger) (un nuevo bloque en la blokchain).
|
||||
|
||||
|
||||
|
||||
Los validadores comparten sus listas con el resto de validadores. Los validadores incorporan los cambios propuetos entre sí y distribuyen una nueva versión de la propuesta del libro contable (ledger).
|
||||
|
||||
|
||||
|
||||
Cuando el 80% de los validadores acuerdan un conjunto de transacciones, crean una nueva instancia del libro contable (ledger) al final de la cadena y empiezan el proceso otra vez. Este proceso de consenso tarda entre 4 y 6 segundos. Puedes monitorizar cómo se crean las instancias del libro contable (ledger) en tiempo real visitando [https://livenet.xrpl.org/](https://livenet.xrpl.org/).
|
||||
|
||||
### ¿Qué redes están disponibles?
|
||||
|
||||
El XRPL está abierto a cualquiera que quiera configurar su propia instancia de servidor rippled y conectarse. El nodo puede monitorizar la red, realizar transacciones, o convertirse en validador. La red XRPL activa se denomina normalmente como _Mainnet_.
|
||||
|
||||
Para los desarrolladores o nuevos usuarios que quieran probar las características de XRPL sin invertir sus propios fondos, existen dos entornos para desarrolladores, _Testnet_ y _Devnet_. Los usuarios pueden crear una cuenta con 1.000 XRP (falsos) y conectarse a cualquiera de los entornos para interactuar con el XRPL.
|
||||
|
||||
Siguiente: [¿Qué es XRP?](what-is-xrp.md)
|
||||
75
@i18n/es-ES/docs/introduction/what-is-xrp.md
Normal file
75
@i18n/es-ES/docs/introduction/what-is-xrp.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
html: what-is-xrp.html
|
||||
parent: introduction.html
|
||||
seo:
|
||||
title: ¿Qué es XRP y por qué es valioso?
|
||||
description: XRP, la criptomoneda respaldada por el XRP Ledger (XRPL), permite transacciones más rápidas y económicas. Descubre cómo opera XRP en una blockchain de código abierto.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# ¿Qué es XRP?
|
||||
|
||||
XRP es la criptomoneda respaldada por el XRP Ledger.
|
||||
|
||||
## ¿Qué es una criptomoneda?
|
||||
|
||||
Una criptomoneda es una moneda virtual o digital que está protegida por criptografía y que es rastreada usando la blockchain. La seguridad y la integridad de las criptomonedas hace casi imposible falsificarlas o generar un doble gasto.
|
||||
|
||||
|
||||
|
||||
Critopmonedas, monedas digitales, y activos digitales, todos caen en la misma categoría general. Las criptomonedas son:
|
||||
|
||||
- nativas digitalmente (quiere decir que se crearon para internet)
|
||||
- programables
|
||||
- rápidas de transferir a un coste bajo
|
||||
- abiertas y trasparentes
|
||||
- no están restringidas por fronteras o gobiernos (por lo que no necesita cuentas nostro que tengan fondos en otro país)
|
||||
- no están sujetas a falsificación
|
||||
- no requieren una cuenta bancaria o infraestructura para liquidar los pagos.
|
||||
|
||||
|
||||
|
||||
Las criptomonedas son _tokens fungibles_. _Fungible_ significa que tu puedes reemplazar un token por otro token de mismo valor. El franqueo es un ejemplo de un token fungible: si cuesta 50 céntimos enviar una carta, puedes utilizar 2 sellos de 25 centimos o 5 de 10 centimos para el envío, porque el franqueo de sellos es fungible (consistente en valor relativo e intercambiable).
|
||||
|
||||
Las criptomonedas además son descentralizadas. No hay una entidad central que dobierna la moneda. Una vez que la transacción está en la blockchain no se puede cambiar. Es dificil censurar una criptomoneda: mientras que el sistema sea los suficientemente descentralizado, nadie puede dar marcha atrás transacciones, congelar balances, o impedir que alguien pueda utilizar un activo digital descentralizado. Las reglas no cambian sin una coordinación significativa entre todos los participantes.
|
||||
|
||||
Las criptomonedas son atractivas para inversores y desarrolladores porque ninguna entidad por sí sola puede "tirar del cable" y hacerlas desaparecer.
|
||||
|
||||
## ¿Pero por qué es valioso?
|
||||
|
||||
|
||||
|
||||
Puede parecer raro que las criptomonedas se basen únicamente en datos informáticos, y no en ninguna tipo de bien tangible como un metal precioso. Tradicionalmente, las monedas se han basado en ganado, conchas de mar, metales raros, piedras u otro objeto físico. Pero estos elementos tienen valor solo porque hubo un acuerdo entre personas de una cultura.
|
||||
|
||||
Aunque puede parecer mucho más seguro tener algo "real en la mano, muchas personas no distinguirán el oro real del falso, o la circonita cúbica de un diamante auténtico. El papel moneda puede ser falsificado. Puedes olvidar que tienes un billete de 10$ en tu bolsillo y arruinarlo al lavarlo. Es costoso almacenar y transportar de manera segura artículos valiosos para pagar.
|
||||
|
||||
El valor de las criptomonedas proviene de la confianza que sus poseedores depositan en la moneda. Debido a la naturaleza distribuida de los registros y la protección criptográfica para asegurar los fondos, las criptomonedas podrían considerarse mucho más robustas, seguras, y convenientes que las monedas fiduciarias tradicionales.
|
||||
|
||||
|
||||
## XRP es una criptomoneda
|
||||
|
||||
El XRP Ledger fue construido entre 2011 y principios de 2012 por Jed McCaleb, Arthur Britto y David Schwartz. En el momento de su creación, había 100 mil millones de XRP. En septiembre de 2012, Jed y Arthur, junto con Chris Larsen formaron Ripple (la compañía, llamada en ese momento OpenCoin Inc.) y decidieron donar 80 mil millones XRP a Ripple a cambio de que Ripple desarrollase en el XRP Ledger.
|
||||
|
||||
|
||||
|
||||
Desde entonces, la compañía ha vendido XRP regularmente, lo ha utilizado para fortalecer los mercados de XRP y mejorar la liquidez de la red, e incentivar el desarrollo del ecosistema. En 2017, la compañía colocó [55 mil millones de XRP en escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) para asegurar que la cantidad que entra al suministro general [crece de manera predecible](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) en el futuro inmediato,. Ripple [sitio de rendimiento del mercado XRP](https://ripple.com/xrp/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) informa cuánto XRP tiene la compañía disponible y cuanto tiene bloqueado en escrow en la actualidad.
|
||||
|
||||
|
||||
|
||||
|
||||
### El nombre
|
||||
|
||||
Originalmente, el XRP Ledger se llamaba "Ripple" por la forma en que la tecnología permitía que los pagos [se propagaran a través de múltiples saltos y monedas](../concepts/tokens/fungible-tokens/rippling.md). Para el activo nativo construido dentro del ledger, los creadores eligieron las siglas "XRP" del término "créditos ripple" o "ripples" y el prefijo X por ser una moneda no nacional según el estandar de la [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html). La compañía se registró como "Ripple Labs". El nombre "XRP" empezó a usarse para referirse al activo en todos los contextos, para evitar confusiones con nombres similares de la tecnología y la compañía, y finalmente la empresa acortó su propio nombre a "Ripple". En mayo de 2018, [la comunidad seleccionó un nuevo símbolo "X"](https://twitter.com/xrpsymbol/status/1006925937571713025) para representar XRP y diferenciarlo del logotipo triskelion con el que se conocía anteriormente tanto a la empresa como al activo digital
|
||||
|
||||
| XRP "X" Logo | Ripple triskelion |
|
||||
|:---------------------------------------|:------------------------------------|
|
||||
|  |  |
|
||||
|
||||
|
||||
### Marca comercial
|
||||
|
||||
"XRP" es una marca registrada de la XRPL Foundation en EE.UU. y otros países como China y Estonia.
|
||||
|
||||
La solicitud de marca se registró en la Oficina de Patentes y Marcas de los Estados Unidos (USPTO) en 2013 con OpenCoin Inc y Ripple Labs Inc como cesionarios. En 2022, la asignación de marca fue actualizada y ahora está asignada a MITTETULUNDUSÜHING XRP LEDGER TRUST (“XRPLF”).
|
||||
|
||||
Siguiente: [Carteras Cripto](crypto-wallets.md)
|
||||
306
@i18n/es-ES/translations.yaml
Normal file
306
@i18n/es-ES/translations.yaml
Normal file
@@ -0,0 +1,306 @@
|
||||
theme.navbar.about: Acerca de
|
||||
theme.navbar.docs: Docs
|
||||
theme.navbar.resources: Recursos
|
||||
theme.navbar.community: Comunidad
|
||||
theme.footer.about: Acerca de
|
||||
theme.footer.docs: Docs
|
||||
theme.footer.resources: Recursos
|
||||
theme.footer.community: Comunidad
|
||||
sidebar.docs: Docs
|
||||
sidebar.docs.tutorials: Tutoriales
|
||||
sidebar.docs.references: Referencias
|
||||
sidebars.resources: Recursos
|
||||
sidebar.resources.codesamples: Ejemplos de código
|
||||
topnav.docs.title: Documentación
|
||||
topnav.docs.description: Sumérgete en la tecnología XRP Ledger y empieza a integrar
|
||||
topnav.resources.current-status: Estado actual
|
||||
topnav.resources.explorer: Explorador del ledger
|
||||
topnav.community.title: Contribuye a la comunidad XRPL
|
||||
topnav.community.description: Únete a la conversación
|
||||
Open Source.: Código abierto
|
||||
Jump to top of page: Saltar arriba
|
||||
Edit page: Editar página
|
||||
Search: Buscar
|
||||
Search site...: Buscar sitio...
|
||||
Search for articles, training, and code samples...: Buscar artículos, entrenamientos, ejemplos de código...
|
||||
Become an XRP Ledger Campus Ambassador: Conviertete en un Embajador de Campus XRP Ledger
|
||||
Join the Student Cohort: Únete al grupo de estudiantes
|
||||
XRPL Campus Ambassadors: Embajadores de Campus XRPL
|
||||
Current Students: Estudiantes actuales
|
||||
Why become an XRPL Campus Ambassador?: ¿Por qué convertirse en un Embajador de Campus?
|
||||
Benefits: Beneficios
|
||||
Join a global cohort of students empowering others to build on the XRPL.: Únete al grupo global de estudiantes animando a otros a construir en el XRPL.
|
||||
Exclusive Opportunities: Oportunidades exclusivasa
|
||||
Education: Educación
|
||||
Tutorials and workshops from leading XRPL and blockchain developers: Tutoriales y workshops de desarrolladores líderes de la blockchain XRPL
|
||||
Swag: Estilo
|
||||
New XRPL swag for Ambassadors and swag to share with other students: Nuevo estilo XRPL para embajadores y estilo para compartir con otros estudiantes
|
||||
Mentorship: Mentorías
|
||||
Career Acceleration: Aceleración de tu carrera
|
||||
Stipend: Paga
|
||||
Should You Apply?: ¿Debería aplicar?
|
||||
Eligibility for XRPL Campus Ambassadors: Requisitos para embajadores de campus XRPL
|
||||
A Leader: Un lider
|
||||
Active: Activo
|
||||
Curious: Curioso
|
||||
Eager to learn more about technical blockchain topics and the XRPL: Con ganas de aprender más sobre los temas técnicos de blockchain y XRPL
|
||||
Passionate: Apasionado
|
||||
Creative: Creativo
|
||||
Ability to think outside the box to grow the XRPL student community: Habilidad para pensar de forma distinta para hacer crecer la comunidad de estudiantes del XRPL
|
||||
Process to become a Campus Ambassador: Proceso para convertirse en embajador de campus
|
||||
How it Works: Cómo funciona
|
||||
Apply now to become an XRPL Campus Ambassador.: Aplica ahora para convertirte en embajador de campus XRPL
|
||||
Apply: Aplicar
|
||||
Submit an application to be considered for the Campus Ambassador program.: Envía una aplicación para ser considerado por el programa de embajador del campus.
|
||||
Interview: Entrevista
|
||||
Join: Únete
|
||||
Learn: Aprender
|
||||
Apply for Fall 2023: Aplicar para otoño de 2023
|
||||
Join a global cohort of Student Ambassadors: Únete al grupo global de estudiantes embajadores
|
||||
Global Community: Comunidad global
|
||||
Stay connected to the XRPL Campus Ambassadors: Mantente en contacto con embajadores de campus XRPL
|
||||
Connect: Conecta
|
||||
MeetUp: Quedadas
|
||||
Attend an XRPL Meetup in your local area: Acude a quedadas XRPL en tu zona
|
||||
Dev.to Blog: Blog Dev.to
|
||||
Read more about the activity of the XRPL Ambassadors: Lee más sobre la actividad de embajadores XRPL
|
||||
Join the conversation on the XRPL Developer Discord: Únete a la conversación del Discord de desarrolladores XRPL
|
||||
Start Building with Example Code: Empiza a construir con ejemplos de código
|
||||
Code Samples: Ejemplos de código
|
||||
Browse sample code for building common use cases on the XRP Ledger: Navega entre los códigos de ejemplo para construir casos de uso comunes en el XRP Ledger
|
||||
Contribute Code Samples: Contribuye con ejemplos de código
|
||||
Help the XRPL community by submitting your<br> own code samples: Ayuda a la comunidad XRPL añadiendo tus propios ejemplos de código
|
||||
The XRPL Community: La comunidad XRPL
|
||||
Find the community on the platforms below: Encuentra a la comunidad en la plataforma de abajo.
|
||||
Join the Conversation: Entra en la conversación
|
||||
Run an XRP Ledger network node: Ejecuta un nodo de la red XRP Ledger
|
||||
Contribute to Consensus: Contribuye al consenso
|
||||
Apply for funding to build your XRPL project: Aplica para financiar la construcción de tu proyecto XRPL
|
||||
Awarded in a single grant: Premiado en una financiación
|
||||
Distributed to grant recipients: Distribuido entre los recibidores de la financiación
|
||||
Open-source projects funded : Proyectos de código abierto financiados
|
||||
Learn More: Leer más
|
||||
Showcase your XRPL project, application or product: Muestra tu proyecto XRPL, aplicación o producto
|
||||
XRPL Community Spotlight: Destacado en la comunidad XRPL
|
||||
Submit Your Projects: Envía tus proyectos
|
||||
Read the Blog: Leer el blog
|
||||
Check out global events across the XRPL community: Consulta eventos globales alrededor de la comunidad XRPL
|
||||
XRPL Events: Eventos XRPL
|
||||
View All Events: Ver todos los eventos
|
||||
Discover your next career opportunity in the XRPL community: Descrube tu próxima oportunidad de carrera en la comunidad XRPL
|
||||
Review guidelines for using XRPL design assets: Revisa las guías para usar los activos de diseño XRPL
|
||||
XRPL Assets: Activos XRPL
|
||||
Download the PDF and Assets: Descargar el PDF y los activos
|
||||
A community-driven resource for all things XRPL.org: XRPとXRP Un recurso para todas las cosas dirigido por la comunidad XRPL.org
|
||||
Contribute to XRPL.org: Contribuye con XRPL.org
|
||||
Read Contributor Guidelines: Leer la guía de contribución
|
||||
Dev Tools: Herramientas de desarrollo
|
||||
Explorers: Exploradores
|
||||
API Access: Acceso a APIs
|
||||
Other: Otro
|
||||
Have an Idea For a Tool?: ¿Tienes una idea para una herramienta?
|
||||
Open a pull Request: Abre un pull request
|
||||
Full documentation index: Índice completo de la documentación
|
||||
See Everything: Ver todo
|
||||
XRP Ledger Developer Resources: Recursos para desarrolladores XRPL
|
||||
Documentation: Documentación
|
||||
rippled API Reference: API rippled de referencia
|
||||
XRP Faucet: Grifo XRP
|
||||
Getting Started with Python: Comienza con Python
|
||||
Websocket API Tool: Herramienta API Websocket
|
||||
XRP Ledger Explorer: Explorador XRP Ledger
|
||||
Advanced Payment Features: Características de pago avanzadas
|
||||
Governance and the Amendment Process: Gobierno y proceso de enmiendas
|
||||
Federated Sidechains: Sidechains federadas
|
||||
On-Chain Finance: Finanzas On-Chain
|
||||
Trade on the decentralized exchange: Comercia en el exchange descentralizado
|
||||
Make payments: Haz pagos
|
||||
Use specialized payment types: Utiliza tipos de pago especializados
|
||||
Tokens: Tokens
|
||||
Non-fungible Tokens: Tokens No Fungibles
|
||||
Issue a stablecoin: Emitir una stablecoin
|
||||
Assign an authorized minter: Asignar un acuñador autorizado
|
||||
Payments: Pagos
|
||||
Peer to peer payments: Pagos Peer to peer
|
||||
Cross-currency payments: Pagos entre divisas
|
||||
Escrows: Escrows
|
||||
Intro to XRP Ledger: Intro to XRP Ledger
|
||||
Accounts: Cuentas
|
||||
Decentralized Exchange: Exchange descentralizado
|
||||
Tokenization: Tokenización
|
||||
Faucets: Grifo XRP
|
||||
Get credentials and test-XRP for XRP Ledger Testnet or Devnet.: Consigue credenciales y XRP de prueba para la Testnet o Devnet de XRP Ledger
|
||||
WebSocket Tool: Herramienta Websocket
|
||||
Send sample requests and get responses from the rippled API.: Envía peticiones de ejemplo y recibe respuestas desde la API rippled
|
||||
Transaction Sender: Enviador de transacciones
|
||||
Concepts: Conceptos
|
||||
Read the Docs: Leer los documentos
|
||||
Tutorials: Tutoriales
|
||||
Get step-by-step guidance to perform common tasks with the XRP Ledger.: Consigue guías paso a paso para tareas comunes con el XRP Ledger
|
||||
View Tutorials: Ver tutoriales
|
||||
References: Referencias
|
||||
View References: Ver referencias
|
||||
Use Cases: Casos de uso
|
||||
Getting Started: Empezar
|
||||
Quickstart to XRP Ledger: Inicio rápido de XRP Ledger
|
||||
An introduction to fundamental aspects of the XRP Ledger.: Una introducción a los aspectos fundamentales del XRP Ledger
|
||||
Get Started: Empieza
|
||||
Watch Full Series: Ver serie completa
|
||||
Interact with the XRP Ledger in a language of your choice: Interactua con el XRP Ledger en un lenguaje de tu elección
|
||||
Explore SDKs: Explora SDKs
|
||||
Intermediate Learning Sources: Fuentes de aprendizaje intermedio
|
||||
Explore, Test, Verify: Explora, prueba, verifica
|
||||
Explore Dev Tools: Explora las herramientas de desarrollo
|
||||
Browse By Recommended Pages: Explora entre las páginas recomendadas
|
||||
Get Free Test XRP: Consigue XRP de prueba gratis
|
||||
Generate Testnet Credentials: Genera credenciales de Testnet
|
||||
See full documentation index: Consulta el índice de la documentación completa
|
||||
Find the XRPL Community Around the World: Encuentra a la comunidad XRPL alrededor del mundo
|
||||
Events: Eventos
|
||||
The XRPL Developer Summit: El encuentro de desarrolladores XRPL
|
||||
Save the Date: Guarda la fecha
|
||||
Upcoming Events: Eventos próximos
|
||||
Explore past community-hosted events: Explora eventos pasados organizados por la comunidad
|
||||
Past Events: Eventos anteriores
|
||||
Sorry, this page is not available in your language.: Lo siento, esta página no está disponible en tu idioma
|
||||
XRPL Developer Funding Programs: Programas de financiación de desarrolladores XRPL
|
||||
Project Resources: Recursos para proyectos
|
||||
Explore funding opportunities for developers and teams: Explora oportunidades de financiación para desarrolladores y equipos
|
||||
Funding Overview: Vistazo de financiaciones
|
||||
XRPL Hackathons: Hackatones XRPL
|
||||
Join an Event: Únete a un evento
|
||||
See Upcoming Events: Consulta eventos próximos
|
||||
Best for: Lo mejor para
|
||||
Software developers and teams building directly on the XRP Ledger: Desarrolladores y equipos de software construyen directamente en el XRP Ledger
|
||||
Required: Necesario
|
||||
Some coding experience: Algo de experiencia
|
||||
Level: Nivel
|
||||
XRPL beginner to advanced developers: Desarrolladores de iniciados a avanzados
|
||||
Funding Levels: Niveles de financiación
|
||||
Prize money and awards: Dinero y premios
|
||||
Fund Your Project: Financia tu proyecto
|
||||
Past awardees include: Los premios pasados incluyen
|
||||
Visit XRPL Grants: Visita las financiaciones de XRPL
|
||||
XRPL intermediate to advanced developers: Desarrolladores de nivel intermedio a avanzados
|
||||
$10,000 - $200,000: 10.000$ ~ 200.000$
|
||||
XRPL Accelerator: Acelerador XRPL
|
||||
Advance your project: Avanza tu proyecto
|
||||
View XRPL Accelerator: Consulta el acelerador XRPL
|
||||
$50,000 (grant) + pitch for venture funding: 50.000$(premio) más pitch para venture funding
|
||||
Provide a Better Alternative to Bitcoin: Ofrece una mejor alternativa a Bitcoin
|
||||
XRPL's Origin: Origen de XRPL
|
||||
XRPL Launches its Native Currency, XRP: XRPL lanza su divisa nativa, XRP
|
||||
OpenCoin Rebranded to Ripple Labs: OpenCoin renombrada como Ripple Labs
|
||||
XRPL Foundation Launched: Se lanza XRPL Foundation
|
||||
The Blockchain<br class=\until-sm\/> Built for Business: La blockchain<br class=\until-sm\/> construida para negocios
|
||||
XRPL | XRP Ledger:
|
||||
Start Building: Empieza a construir
|
||||
Why developers choose the XRP Ledger: ¿Por qué los desarrolladores eligen el XRP Ledger?
|
||||
Public and Decentralized: Público y descentralizado
|
||||
Open source, open to anyone to build on, maintained by the community: Código abierto, abierto a cualquiera que quiera construir, mantenido por la comunidad
|
||||
Streamlined Development: Desarrollo simplificado
|
||||
Intentional innovations, tools and documentation reduce time to market: Las innovaciones, herramientas y documentación intencionales reducen el tiempo de comercialización
|
||||
High Performance: Alto rendimiento
|
||||
Thousands of transactions settled in seconds: Miles de transacciones realizadas en segundos
|
||||
Low Cost: Bajo coste
|
||||
Motivated Community: Comunidad motivada
|
||||
Proven Reliability: Fiabilidad probada
|
||||
Powerful Features: Funcionalidades potentes
|
||||
Cross-Currency Payments: Pagos entre divisas
|
||||
Payment <br class='until-sm'/>Channels: Canales de<br class='until-sm'/>Pago
|
||||
Batched micropayments with unlimited speed, secured with XRP: Micropagos en lotes con velocidad ilimitada, segurados con XRP
|
||||
Multi-Signing: Multi-firma
|
||||
Flexible options for custody and security of on-ledger accounts: Opciones flexibles para la custodia y seguridad de cuentas en el ledger
|
||||
Choose a path, and bring your project to life on the XRP Ledger: Elige un camino, y haz tu proyecto realidad en el XRP Ledger
|
||||
Where to Start: Dónde empezar
|
||||
Quickstart: Inicio rápido
|
||||
Access everything you need to get started working with the XRPL: Accede a todo lo que necesitas para empezar a trabajar con XRPL
|
||||
Guided Tutorials: Tutoriales guiados
|
||||
Follow step-by-step guides for frequent tasks: Sigue las guías paso a paso para tareas frecuentes
|
||||
XRPL Fundamentals: Fundamentos del XRPL
|
||||
Read about the XRPL’s foundational concepts: Lee sobre los conceptos fundamentales del XRPL
|
||||
Choose a Language: Elige un idioma
|
||||
Get Inspired: Inspírate
|
||||
See what your peers have built on the XRPL: Observa lo que otros compañeros han construido en el XRPL
|
||||
Our Shared Vision for XRPL’s Future: Nuestra visión compartida del futuro del XRPL
|
||||
Preview New Features: Previsualiza nuevas funcionalidades
|
||||
In Development: En desarrollo
|
||||
Smart Contracts: Smart Contracts
|
||||
Enabled: Activado
|
||||
Non-Fungible Tokens: Tokens no fungibles
|
||||
Join the Community <br class=\until-sm\/> at XRPL.org: Únete a la comunidad<br class=\until-sm\/> en XRPL.org
|
||||
Get Involved: Únete
|
||||
Today’s Value, Tomorrow’s Vision: El valor de hoy, la visión del mañana
|
||||
XRPL Today, XRPL Tomorrow: XRPL hoy, XRPL mañana
|
||||
Building for the Future: Construyendo por el futuro
|
||||
Consensus protocol is efficient and sustainable: El protocolo de consenso es eficiente y sostenible
|
||||
A Sustainable Future: Un futuro sostenible
|
||||
What makes the XRPL sustainable?: ¿Qué hace al XRPL sostenible?
|
||||
Featured companies & projects running on the XRP Ledger.: Compañías y proyectos destacados en el XRP Ledger
|
||||
Sustainable Projects: Proyectos sostenibles
|
||||
See More: Ver más
|
||||
How can businesses and developers connect and contribute?: ¿Cómo pueden los negocios y desarrolladores conectar y contribuir?
|
||||
Join the Community: Únete a la comunidad
|
||||
Blog: Blog
|
||||
Code: Código
|
||||
References and APIs: Referencia y APIs
|
||||
Everything You Need to Know: Todo lo que necesitas saber
|
||||
XRP Ledger address, transaction ID, or ledger index: Dirección XRP Ledger, ID de transacción, o índice del ledger
|
||||
Try an account like <em>rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn</em>.: Prueba una cuenta como <em>rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn</em>
|
||||
Get info: Consigue información
|
||||
Result: Resultado
|
||||
Permalink: Permalink
|
||||
Explorer: Explorador
|
||||
expand all: Ampliar todo
|
||||
collapse all: Reducir todo
|
||||
(last 20): (últimos 20)
|
||||
expand tx: Ampliar tx
|
||||
next 20: Siguientes 20
|
||||
prev 20: Previos 20
|
||||
Status: Estado
|
||||
Not Connected: No conectado
|
||||
Transaction History: Historial de transacciones
|
||||
Initialize: Inicializar
|
||||
Set up the necessary Testnet XRP addresses to send test payments.: Prepara lo necesario para direcciones XRP de Testnet y enviar pagos de prueba
|
||||
Destination Address: Dirección de destino
|
||||
Send transactions to this XRP Testnet address: Envía transacciones a esta dirección XRP Testnet
|
||||
Send Transaction: Envía una transacción
|
||||
(loading): (Cargando)
|
||||
Send XRP Payment: Envía un pago XRP
|
||||
drops of XRP: XRP drops
|
||||
Send a <a href=\send-xrp.html\>simple XRP-to-XRP payment</a>.: Envía un <a href=\send-xrp.html\>pago XRP-XRP sencillo</a>.
|
||||
(Getting ready to send partial payments): (Preparando para enviar pagos parciales)
|
||||
Send Partial Payment: Envía pago parcial
|
||||
Create Escrow: Crear un Escrow
|
||||
seconds: segundos
|
||||
Finish automatically: Finalizar automáticamente
|
||||
(Waiting to release Escrow when it's ready): （Esperando a la liberación del Escrow cuando esté listo)
|
||||
Create Payment Channel: Crear canal de pago
|
||||
Send Issued Currency: Envia divisas emitidas
|
||||
Trust for: Confianza para
|
||||
Security: Seguridad
|
||||
Release Notes: Notas de la versión
|
||||
Custody: Custodia
|
||||
Infrastructure: Infraestructura
|
||||
Carbon Markets/Sustainability: Mercados de Carbono/Sostenibilidad
|
||||
Developer Tooling: Herramientas de desarrollo
|
||||
Gaming: Gaming
|
||||
Wallet: Cartera
|
||||
Ledger City is a crypto real estate game powered by the XRP Ledger.: Ledger City es un juego inmobiliario el XRP Ledger
|
||||
Interoperability: Interoperabilidad
|
||||
Ripple's CBDC Platform: CBDC Platform de Ripple
|
||||
Ripple's On-Demand Liquidity: On-Demand Liquidity de Ripple
|
||||
Exchanges: Exchanges
|
||||
XRPL Rosetta explores fiat data on XRPL through visualization.: XRPL Rosetta explora datos de dinero fiat en el XRPL a través de la visualización
|
||||
XRPL.org's Ledger Explorer is a block explorer of the XRP Ledger.: El explorador de ledgers de XRPL.org es el explorador de bloques para el XRP Ledger
|
||||
Xumm Wallet is a non custodial wallet with superpower for the XRP Ledger.: Xumm Wallet es una cartera sin custodia con superpoderes para el XRP Ledger
|
||||
Web Monetization: Monetización web
|
||||
Sustainability: Sostenibilidad
|
||||
CBDCs: CBDC
|
||||
Cancel: Cancelar
|
||||
Featured Categories: Categorías destacadas
|
||||
Other Categories: Otras categorías
|
||||
Proven Powerful for Innovation: Comprobadamente potente para la innovación
|
||||
XRPL Use Cases: Casos de uso XRPL
|
||||
Building businesses and creating new value: Construyendo negocios y nuevo valor
|
||||
XRPL Ecosystem: Ecosistema XRPL
|
||||
@@ -1,16 +1,10 @@
|
||||
---
|
||||
html: faq.html
|
||||
parent: xrp-ledger-overview.html
|
||||
seo:
|
||||
description: XRP Ledger、XRPLエコシステム、コミュニティに関するよくある質問にお答えします。
|
||||
subtitle: XRPLについての質問にお答えします
|
||||
top_nav_grouping: 概要
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
#template: page-faq2.html.jinja
|
||||
filters:
|
||||
- faq
|
||||
name: よくある質問
|
||||
---
|
||||
# よくある質問
|
||||
|
||||
@@ -28,7 +22,7 @@ name: よくある質問
|
||||
|
||||
#### プルーフ・オブ・ワーク(PoW)が最善の検証メカニズムではないのですか？
|
||||
|
||||
プルーフ・オブ・ワークは、信頼できる第三者を必要とせずに二重支出の問題を解決する最初のコンセンサンス・メカニズムでした。[XRP Ledgerのコンセンサス。メカニズム](../docs/concepts/consensus-protocol/index.md)は、同じ問題をはるかに速く、安く、より良いエネルギー効率で解決します。
|
||||
プルーフ・オブ・ワークは、信頼できる第三者を必要とせずに二重支出の問題を解決する最初のコンセンサンス・メカニズムでした。[XRP Ledgerのコンセンサスメカニズム](../docs/concepts/consensus-protocol/index.md)は、同じ問題をはるかに速く、安く、より良いエネルギー効率で解決します。
|
||||
|
||||
|
||||
#### どのようにして持続可能なブロックチェーンを実現するのでしょうか？
|
||||
@@ -43,7 +37,7 @@ name: よくある質問
|
||||
|
||||
#### XRPLは決済専用ではないのですか？
|
||||
|
||||
いいえ。当初は決済のユースケース向けに開発されましたが、台帳であるXRP Ledgerとそのネイティブ・デジタルアセットであるXRPの両方は、NFTなどのブロックチェーンの革新的ユースケースで更に人気を集めています。自動マーケットメーカー(AMM)、XRPL Labsのスマートコントラクト機能Hooks、相互運用サイドチェーンの開発などが現在進行中です。
|
||||
いいえ。当初は決済のユースケース向けに開発されましたが、台帳であるXRP Ledgerとそのネイティブ・デジタルアセットであるXRPの両方は、NFTなどのブロックチェーンの革新的ユースケースで更に人気を集めています。自動マーケットメーカー(AMM)、スマートコントラクト機能Hooks、相互運用サイドチェーンの開発などが現在進行中です。
|
||||
|
||||
|
||||
## バリデータ（検証者）とユニークノードリスト
|
||||
@@ -67,7 +61,7 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ
|
||||
|
||||
#### どのUNLを選択すればよいですか?
|
||||
|
||||
バリデータは誰でも実行できるため、信頼できるバリデータを選ぶ責任はネットワーク参加者にあります。現在、RippleとXRP Ledger財団が、過去の実績、証明された身元、責任あるITポリシーに基づき、高品質なバリデータの推奨デフォルトリストを公表していることが知られています。 しかし、すべてのネットワーク参加者は、自身が信頼できるバリデータを選択することができ、上記の2つの発行者のいずれかに従う必要はありません。
|
||||
バリデータは誰でも実行できるため、信頼できるバリデータを選ぶ責任はネットワーク参加者にあります。現在、RippleとXRP Ledger財団が、過去の実績、証明された身元、責任あるITポリシーに基づき、高品質なバリデータの推奨デフォルトリストを公表していることが知られています。しかし、すべてのネットワーク参加者は、自身が信頼できるバリデータを選択することができ、上記の2つの発行者のいずれかに従う必要はありません。
|
||||
|
||||
|
||||
#### RippleがそのUNLの採用を推奨しているなら、それは中央集権的なシステムを形成することにならないのですか?
|
||||
@@ -77,7 +71,7 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ
|
||||
|
||||
#### バリデータにとってインセンティブとなるものは何ですか?
|
||||
|
||||
バリデータを運営する主なインセンティブは、ネットワークの安定的な運用と健全な進化を維持・保護することです。XR Ledgerの進化を決定するのはバリデータであり、XRP Ledgerを利用する、あるいはXRP Ledgerに依存するビジネスには、ネットワークの信頼性と安定性を確保するインセンティブが内在しています。バリデータはまた、このように貢献することでコミュニティからの評価と信頼を得ることができます。
|
||||
バリデータを運営する主なインセンティブは、ネットワークの安定的な運用と健全な進化を維持・保護することです。XRP Ledgerの進化を決定するのはバリデータであり、XRP Ledgerを利用する、あるいはXRP Ledgerに依存するビジネスには、ネットワークの信頼性と安定性を確保するインセンティブが内在しています。バリデータはまた、このように貢献することでコミュニティからの評価と信頼を得ることができます。
|
||||
|
||||
ネットワークに参加するためにXRP Ledgerのサーバを運営する場合やバリデータを運営するための追加コストや手間は最小限です。つまり、ビットコインにおけるマイニング報酬のような追加のインセンティブは必要ありません。Rippleはバリデータを運用するための報酬としてXRP支払うことはしないため、そのようなインセンティブがバリデータの行動を歪めることはありません。
|
||||
|
||||
@@ -99,6 +93,7 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ
|
||||
|
||||
XRP Ledgerのコンセンサスメカニズムが不利な状況でどのように動作するかについては、[攻撃と失敗モードに対するコンセンサスの保護](../docs/concepts/consensus-protocol/consensus-protections.md)をご覧ください。
|
||||
|
||||
|
||||
#### XRP Ledgerでは正式なバリデータのオンボーディングプロセスを使用していますか?
|
||||
|
||||
いいえ。XRP Ledgerは、中央権限のないシステムであるため、正式なバリデータのオンボーディングプロセスのようなものは存在しません。
|
||||
@@ -107,6 +102,7 @@ XRP Ledgerのコンセンサスメカニズムが不利な状況でどのよう
|
||||
|
||||
推奨事項やベストプラクティスについては、[バリデータとしての`rippled`の実行](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。
|
||||
|
||||
|
||||
#### デフォルトUNL(dUNL)がネットワークに最も影響力を持つなら、XRPLは中央集権的ではないでしょうか？
|
||||
|
||||
バリデータはdUNLや広く使われているUNLを使わないこともできます。誰でもいつでも自由にUNLを作ることができます。
|
||||
@@ -138,17 +134,18 @@ Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、
|
||||
[XRP Forensics / xrplorer](https://xrplorer.com/)は、XRP Ledgerのマネーロンダリング、詐欺、詐欺、不正使用を追跡し、最小限に抑えるための勧告リストを維持しています。取引所やその他のサービス・プロバイダは、金融犯罪を防止し対応するためにこのサービスを利用することができます。
|
||||
|
||||
|
||||
## セキュリティー上の懸念
|
||||
## セキュリティ上の懸念
|
||||
|
||||
|
||||
#### サードパーティにより提供されたコードは審査プロセスはどのようになっていますか？
|
||||
|
||||
コードへの貢献のプロセスは、開発者が [`rippled` リポジトリ](https://github.com/xrplf/rippled/) のようなソースコードリポジトリに [プルリクエスト](https://docs.github.com/ja/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) を行うことから始まります。
|
||||
コードへの貢献のプロセスは、開発者が[`rippled`リポジトリ](https://github.com/xrplf/rippled/)のようなソースコードリポジトリに[プルリクエスト](https://docs.github.com/ja/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)を行うことから始まります。
|
||||
|
||||
このプルリクエストは、自動化された単体テストと統合テスト、そしてプルリクエストが影響するコード領域で重要な専門知識を持つ複数の開発者によりコードレビューが行われます。
|
||||
|
||||
プルリクエストが自動テストに合格し、レビュアーの承認を受けると、信頼できる[リポジトリのメンテナ](https://opensource.guide/best-practices/)が次のベータ版に含めるための手続きを行います。
|
||||
|
||||
|
||||
#### RippleはXRP LedgerまたはXRP Ledgerネットワークを所有または管理していますか?
|
||||
|
||||
いいえ、RippleはXRP LedgerまたはXRP Ledgerネットワークを所有も管理もしていません。
|
||||
@@ -158,6 +155,6 @@ Rippleは、コアとなるXRP Ledgerサーバ（[`rippled`](https://github.com/
|
||||
いくつかの団体が推奨バリデータリスト（UNL）を公開しています。2023年7月現在、RippleはデフォルトのUNLにある35のバリデータのうち1つのみを実行しています。
|
||||
|
||||
|
||||
#### Rippleは検証用のコードベースとユーザソフトウェア用のコードベースを区別していますか?
|
||||
#### XRP Ledgerは検証用のコードベースとユーザソフトウェア用のコードベースを区別していますか?
|
||||
|
||||
XRP Ledgerの[クライアントライブラリ](../docs/references/client-libraries.md)は、ソフトウェア開発者向けのものです。これらのライブラリは、ネットワークを支え、トランザクションを検証する[XRP Ledgerのコアサーバ](../docs/concepts/networks-and-servers/index.md)とは異なるコードベースとリポジトリを持っています。
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
| フィールド | 値 | 説明 |
|
||||
|:--------------------------------------|:--------------------|:---------------|
|
||||
| `AffectedNodes` | 配列 | このトランザクションで作成、削除、または修正された[レジャーオブジェクト](../references/protocol/ledger-data/ledger-entry-types/index.md)のリストと、個々のオブジェクトに対する具体的な変更内容。 |
|
||||
| `DeliveredAmount` | [通貨額][] | **廃止予定。**`delivered_amount`で置き換えられます。Partial Paymentsでない場合は省略されます。 |
|
||||
| `DeliveredAmount` | [通貨額](../references/protocol/data-types/basic-data-types.md#通貨額の指定) | **廃止予定。**`delivered_amount`で置き換えられます。Partial Paymentsでない場合は省略されます。 |
|
||||
| `TransactionIndex` | 符号なし整数 | トランザクションが記録されているレジャーでのトランザクションの位置。この配列は0から始まります。（例えば、値が`2`の場合、そのレジャーの3番目のトランザクションであったことを意味します）。 |
|
||||
| `TransactionResult` | 文字列 | トランザクションが成功したか、どのような理由で失敗したかを示す[結果コード](../references/protocol/transactions/transaction-results/index.md)。 |
|
||||
| [`delivered_amount`](../references/protocol/transactions/metadata.md#delivered_amount) | [通貨額][] | `Destination`アカウントが実際に受取った[通貨額][]。このフィールドは、トランザクションが[Partial Payments](../concepts/payment-types/partial-payments.md)であるかどうかにかかわらず、送金された金額を特定するために使用します。{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.27.0" %}新規: rippled 0.27.0{% /badge %} |
|
||||
| [`delivered_amount`](../references/protocol/transactions/metadata.md#delivered_amount) | [通貨額](../references/protocol/data-types/basic-data-types.md#通貨額の指定) | `Destination`アカウントが実際に受取った通貨額。このフィールドは、トランザクションが[Partial Payments](../concepts/payment-types/partial-payments.md)であるかどうかにかかわらず、送金された金額を特定するために使用します。 |
|
||||
|
||||
@@ -62,7 +62,7 @@ labels:
|
||||
|
||||
運用アドレスと同様に、待機アドレスは、顧客やパートナーではなく、発行アドレスとトラストラインを設定しなければなりません。運用アドレスに適用されるすべての注意事項は、待機アドレスにも適用されます。
|
||||
|
||||
### スタンバイアドレスの漏えい
|
||||
### 待機アドレスの漏えい
|
||||
|
||||
待機アドレスの秘密鍵が漏えいした場合、その影響は運用アドレスの場合と同じです。悪意のある第三者は、待機アドレスが保有するすべての残高を盗むことができ、金融機関は顧客やパートナーが何もしなくても、新しい待機アドレスに切り替えることができます。
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
html: decentralized-identifiers.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Decentralized identifiers enable verifiable, decentralized digital identities.
|
||||
description: 分散型IDは、検証可能な分散型デジタルIDを可能にします。
|
||||
status: not_enabled
|
||||
labels:
|
||||
- DID
|
||||
@@ -15,9 +15,11 @@ _([DID Amendment][] {% not-enabled /%} が必要です。)_
|
||||
|
||||
DIDの主な基本原則は以下の通りです。
|
||||
|
||||
- **分散型:** 中央の発行機関がDIDを管理することがないため、所有者はDIDを更新、解決、または無効化することができます。
|
||||
- **分散型:** 中央の発行機関がDIDを管理することがないため、所有者はDIDを更新、解決、または無効化することができます。また、DIDは通常ブロックチェーン上に保存され、常に確認が可能なため、あなたの本人確認も非常に利用しやすくなります。
|
||||
|
||||
- **暗号的に検証可能:** DIDは暗号証明によって検証されるため、改ざんが不可能で安全です。
|
||||
- **検証可能な資格情報(Verifiable Credentials):** 誰でもDIDを作成し、その情報を偽造することができます。DIDの真正性を証明するために、ユーザは暗号的に安全で改ざんできない検証可能な資格情報(Verifiable Credentials/VC)を提供しなければなりません。
|
||||
|
||||
DIDエコシステムには3つの当事者がいます。_ユーザ_、_発行者_、_検証者_ です。ユーザはDIDを管理しますが、オフラインで情報を検証するには信頼できる _発行者_ が必要です。_発行者_ は検証可能な資格情報を提供し、ユーザはそれをユーザの身元を確認する必要がある _検証者_ に渡します。DIDエコシステムの詳細については、こちらをご覧ください。[エコシステムの概要](https://www.w3.org/TR/vc-data-model/#ecosystem-overview)
|
||||
|
||||
- **相互運用性:** DIDは、W3CのDID規格を認識するあらゆるソリューションに対してオープンです。つまり、DIDは様々なデジタルトランザクションやインタラクションの認証や信頼の確立に使用することができます。
|
||||
|
||||
@@ -28,11 +30,8 @@ DIDの主な基本原則は以下の通りです。
|
||||
|
||||
1. XRPLアカウント保有者は、アカウントによって管理されるDIDを生成します。
|
||||
2. DIDはW3C仕様で定義されたDIDドキュメントと関連付けられます。
|
||||
3. DIDは次のようなデジタルタスクに使用されます：
|
||||
- デジタル文書への署名
|
||||
- 安全なオンライントランザクション。
|
||||
- Webサイトへのログイン
|
||||
4. 検証者は、対象者の身元を確認するために、DIDからそのドキュメントへ解決します。
|
||||
3. ユーザは、デジタル上のタスクのために、自分のDIDとVCを検証者に提供します。
|
||||
4. 検証者はDIDをそのドキュメントに変換し、VCを使用してその真正性を検証します。
|
||||
|
||||
|
||||
## DIDドキュメント
|
||||
@@ -73,7 +72,7 @@ DIDドキュメントの主要なプロパティの詳細については[Decentr
|
||||
## プライバシーとセキュリティの懸念
|
||||
|
||||
- XRPLアカウントの秘密鍵を管理する人は誰でも、DIDとそれが解決するDIDドキュメントへの参照を管理します。秘密鍵が漏洩しないように注意してください。
|
||||
- DIDドキュメントにはどのような内容でも含めることができますが、検証方法とサービスポイントに限定すべきです。XRPL上のDIDは誰でも解決できるので、個人情報を含めるべきではありません。
|
||||
- DIDドキュメントにはどのような内容でも含めることができますが、検証方法とサービスポイントに限定すべきです。XRPL上のDIDは公開情報であるので、個人情報を含めるべきではありません。
|
||||
- IPFSは誰でも分散ネットワークのノードにコンテンツを保存できます。よくある誤解は、誰でもそのコンテンツを編集できるということです。しかし、IPFSのコンテンツアドレス指定可能性は、編集されたコンテンツがオリジナルとは異なるアドレスを持つことを意味します。どんなエンティティでもXRPLアカウントの`DIDDocument`または`URI`フィールドでアンカーされたDIDドキュメントをコピーすることはできますが、対応する`DID`オブジェクトを作成した秘密鍵をコントロールしない限り、ドキュメント自体を変更することはできません。
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
html: automated-market-makers.html
|
||||
parent: decentralized-exchange.html
|
||||
seo:
|
||||
title: 自動マーケットメーカー(AMM)とは?
|
||||
description: 自動マーケットメーカー（AMM）は、資産ペア間の流動性を提供し、分散型取引所のオーダーブックを補完すると同時に、流動性提供者に利益を提供します。
|
||||
labels:
|
||||
- XRP
|
||||
@@ -9,11 +10,12 @@ labels:
|
||||
- AMM
|
||||
---
|
||||
# 自動マーケットメーカー
|
||||
|
||||
_([AMM amendment][])_
|
||||
|
||||
自動マーケットメーカー(AMM)は、XRP Ledgerの分散型取引所において流動性を提供するスマートコントラクトです。個々のAMMは2つの資産のプールを保有し、数式で定められた取引レートでユーザがその2つの資産間でスワップを可能とします。
|
||||
|
||||
任意の資産ペアに対して、最大1つのAMMが元帳に存在することができます。AMMはそのペアが存在しない場合、誰でも作成することができ、また既存のAMMに預けることもできます。AMMに資産を預ける人は、流動性供給者(LP/Liquidity Provider)と呼ばれ、AMMから「LPトークン」を受け取ります。LPトークンによって、流動性供給者は以下のことが可能になります。
|
||||
任意の資産ペアに対して、最大1つのAMMがレジャーに存在することができます。AMMはそのペアが存在しない場合、誰でも作成することができ、また既存のAMMに預けることもできます。AMMに資産を預ける人は、流動性供給者(LP/Liquidity Provider)と呼ばれ、AMMから「LPトークン」を受け取ります。LPトークンによって、流動性供給者は以下のことが可能になります。
|
||||
|
||||
- LPトークンを、AMMのプール内の資産の一部（手数料を含む）と交換する。
|
||||
- AMMの手数料設定を変更するために投票する。票は、投票者が保有するLPトークンの数に基づいて重み付けされます。
|
||||
@@ -27,6 +29,12 @@ AMMは2つの異なる資産を保有します。このうち最大でも片方
|
||||
|
||||
ユーザが分散型取引所で取引を行う場合、[オファー](offers.md)と[クロスカレンシー決済](../../payment-types/cross-currency-payments.md)は自動的にAMMを使用してトランザクションを成立させることが出来ます。トランザクションは低コストで取引を行えるように、オファー、AMM、またはその両方の組み合わせで実行されます。
|
||||
|
||||
{% admonition type="info" name="注記" %}
|
||||
|
||||
`Payment`または`OfferCreate`トランザクションがAMMとやり取りしたかどうかは、トランザクションメタデータにある[`RippleState`](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)レジャーエントリを確認することで判断できます。`Flags`値が`16777216`の場合、AMMの流動性が消費されたことを示します。
|
||||
|
||||
{% /admonition %}
|
||||
|
||||
AMMは、プール内の資産残高に基づき取引レートを設定します。AMMに対して取引を行うと、AMMが保有する資産残高の変動に応じて、取引レートが調整されます。一方の資産の量が減れば、その資産の価格が上がり、他方の資産の量が増えれば、その資産の価格が下がります。AMMは、プール内の残高が多いほど、一般的により良い取引レートを提供します。同一取引であればプール内の残高が大きい方がAMMの資産バランスに生じる変化は小さくなるからです。AMMの2つの資産のバランスが崩れれば崩れるほど、交換レートは極端に悪化します。
|
||||
|
||||
また、AMMは交換レートに加え、一定割合の取引手数料を徴収しています。
|
||||
@@ -41,6 +49,7 @@ XRP Ledgerの実装は、重みパラメータを0.5とした _幾何平均_ AMM
|
||||
- 資産が、発行者が[認可トラストライン](../fungible-tokens/authorized-trust-lines.md)を使用しているトークンである場合、AMMの作成者はそれらのトークンを保有する権限がなければなりません。トラストラインが認可されているユーザだけが、そのトークンをAMMに預けたり引き出したりすることができます。
|
||||
- [Clawback Amendment][] が有効な場合、Clawbackが有効なトークンでAMMを作成することはできません。
|
||||
|
||||
|
||||
## LPトークン
|
||||
<!-- TODO: add diagrams showcasing flow of funds -->
|
||||
AMMの作成者は、最初の流動性供給者となり、AMMのプール内の資産の100％の所有権を表すLPトークンを受け取ります。LPトークンの一部または全部を交換して、現在のプール残高に比例した資産をAMMから引き出せます。(この比率は、人々がAMMに対して取引を行うにつれて変化します）AMMは、同時に両方の資産を引き出す際に手数料はかかりません。
|
||||
@@ -68,9 +77,11 @@ LPトークンは、160ビットの16進法["非標準"フォーマット](../..
|
||||
|
||||
### オークションスロット
|
||||
|
||||
これまでの自動マーケットメーカーとは異なり、XRP LedgerのAMMのデザインには、流動性供給者が24時間の取引手数料の割引を得るために入札することができる _オークションスロット_ 機能があります。入札はLPトークンで支払う必要があり、落札に使用したLPトークンはAMMに返還されます。一度に複数のアカウントがオークションスロットを保持することはできませんが、落札者は割引を得るために追加で最大4つのアカウントを指定することができます。最低落札価格は設定されていませんが、もしその枠が埋まっている場合は、現在の枠の所有者に競り勝たなければなりません。もし誰かがあなたの入札を退けた場合、残り時間に応じて、落札額の一部が返金されます。アクティブなオークションスロットを保持している限り、そのAMMに対しては通常の取引手数料の1/10の手数料で取引を行うことができます。
|
||||
従来の自動マーケットメーカーとは異なり、XRP LedgerのAMMには、流動性供給者が24時間の取引手数料の割引を得るために入札できる _オークションスロット_ があります。入札はLPトークンで支払われ、AMMに返却されます。他のブロックチェーンとは異なり、AMMの資産価格が外部市場で大きく変動すると、トレーダーはAMMから利益を得るために裁定取引を行うことができますが、これは流動性供給者に損失をもたらします。オークションメカニズムは、その価値の一部を流動性供給者に返し、AMMの価格をより迅速に外部市場とバランスを取ることを意図しています。
|
||||
|
||||
どのようなAMMであっても、その資産の価格が外部市場で大きく変動すると、トレーダーは裁定取引によってAMMから利益を得ることができ、その結果、流動性供給者は損失を被ることになります。オークションの仕組みは、より多くの価値を流動性供給者に還元し、AMMの価格をより迅速に外部市場とのバランスに戻すことを意図しています。
|
||||
一度に複数のアカウントがオークションスロットを保持することはできませんが、入札者は割引を受けるために最大4つのアカウントを指定することができます。スロットが現在使用中の場合、現在のスロット保持者を追い出すために入札する必要があります。追い出された場合、残り時間に応じて一部の入札額が返却されます。アクティブなオークションスロットを保持している間は、そのAMMに対して取引を行う際に、通常の取引手数料の1/10（十分の一）の割引が適用されます。
|
||||
|
||||
オークションスロットの最小入札額は、空または期限切れの場合、現在のLPトークンの総数に取引手数料を掛けたものを25で割ったものです。(擬似コードで表すと、`MinBid = LPTokens * TradingFee / 25`です。) オークションスロットが占有されている場合、現在のスロット保持者が支払った金額の105%までの最小入札額を支払う必要があります。
|
||||
|
||||
|
||||
## 台帳上の表示
|
||||
|
||||
@@ -38,7 +38,7 @@ XRP Ledger上のステーブルコインと認可トラストラインの使用
|
||||
|
||||
### RequireAuthの有効化
|
||||
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使って、`asfRequireAuth`フラグを使ってRequire Authを有効にする[AccountSetトランザクション][]を送信する例です。（このメソッドは、アドレスが発行アドレス、運用アドレス、スタンバイアドレスのいずれであっても同様に機能します。）
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使って、`asfRequireAuth`フラグを使ってRequire Authを有効にする[AccountSetトランザクション][]を送信する例です。（このメソッドは、アドレスが発行アドレス、運用アドレス、待機アドレスのいずれであっても同様に機能します。）
|
||||
|
||||
リクエスト:
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
---
|
||||
# パス
|
||||
|
||||
XRP Ledgerでは、[トークン](../index.md)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)のオーダーを介して送金元と受取人を結び付けることで、[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
XRP Ledgerでは、[トークン](../index.md)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)の注文と[自動マーケットメーカー](../../../concepts/tokens/decentralized-exchange/automated-market-makers.md)を介して送金元と受取人を結び付けることで、[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
|
||||
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
|
||||
|
||||
@@ -20,13 +20,13 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
|
||||
|
||||
* 同一通貨の別のアドレスを通じたRippling
|
||||
* オーダーブックでの通貨の取引
|
||||
* オーダーブックとAMMでの通貨の取引
|
||||
|
||||
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.md)をご覧ください。
|
||||
|
||||
通貨取引ステップの場合、パスステップにより変換先の通貨が指定されますが、オーダーブックにはオファーの状態は記録されません。レジャーが検証されるまではトランザクションの正規の順序は最終的ではないため、トランザクションの検証が完了するまでは、トランザクションがどのオファーをとるかは不明です。（各トランザクションは最終レジャーでの実行時に利用可能なオファーの中から最適なオファーをとるため、経験に基づいて推測することができます。） <!-- STYLE_OVERRIDE: will -->
|
||||
[トークンとXRPの交換](../decentralized-exchange/index.md)は、オーダーブックまたはAMMを介して行われます。トランザクションは、送金元と受取人の間で最も良い交換レートを提供するオーダーブックまたはAMMを見つけるために、パスのステップを使用します。パスのステップは、通貨の変換先を指定しますが、オーダーブックのOfferの状態を記録しません。トランザクションの順序は、レジャーが検証されるまで確定しないため、トランザクションが取引するOfferやAMMを確定することはできません。(ただし、各トランザクションは最終的なレジャーで最良の利用可能な交換レートを取得します。)
|
||||
|
||||
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](../transfer-fees.md)、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
|
||||
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](../transfer-fees.md)、AMM手数料、トラストライン残高の増減、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
|
||||
|
||||
[{% inline-svg file="/docs/img/paths-examples.ja.svg" /%}](/docs/img/paths-examples.ja.svg "3つのパスの例を示す図")
|
||||
|
||||
@@ -65,7 +65,7 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
* トランザクションで（イシュアーに関係なく）1種類の通貨のみが使用される場合、デフォルトパスでは支払いが、関連するアドレスを通じてRipplingされると想定されます。このパスは、これらのアドレスがトラストラインで接続されている場合にのみ機能します。
|
||||
* `SendMax`が省略されているか、または`SendMax`の`issuer`が送金元の場合、デフォルトパスが機能するためには送金元`Account`から宛先`Amount`の`issuer`へのトラストラインが必要です。
|
||||
* `SendMax`と`Amount`に異なる`issuer`値が指定されており、そのいずれも送金元または受取人ではない場合、これらの2つのイシュアー間のトラストラインでRipplingが必要となるため、デフォルトパスは有用ではない可能性があります。一般にイシュアーが互いに直接信頼し合うことはお勧めしません。
|
||||
* クロスカレンシー支払いの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックを使用します。
|
||||
* クロスカレンシー支払いの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックやAMMを使用します。
|
||||
|
||||
有効なすべてのデフォルトパスを次の図に示します。
|
||||
[{% inline-svg file="/docs/img/default-paths.ja.svg" /%}](/docs/img/default-paths.ja.svg "デフォルトパスの図")
|
||||
@@ -80,8 +80,8 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
| フィールド | 値 | 説明 |
|
||||
|:-----------|:-----------------------|:---------------------------------------|
|
||||
| `account` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは指定されたアドレスを通じたRipplingを表します。このステップに`currency`フィールドまたは`issuer`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `currency` | 文字列 - 通貨コード | _（省略可）_ 指定されている場合、このパスステップはオーダーブックを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `issuer` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨のイシュアーを定義します。XRP以外の`currency`のステップでこのフィールドが省略されている場合、パスの直前のステップがイシュアーを定義します。`currency`が省略され、このフィールドが指定されている場合、イシュアーが異なる同名の通貨間でオーダーブックを使用するパスステップを示します。`currency`がXRPの場合は省略する必要があります。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `currency` | 文字列 - 通貨コード | _（省略可）_ 指定されている場合、このパスステップはオーダーブックやAMMを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `issuer` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨の発行者を定義します。XRP以外の`currency`のステップでこのフィールドが省略されている場合、パスの直前のステップが発行者を定義します。`currency`が省略され、このフィールドが指定されている場合、発行者が異なる同名の通貨間でオーダーブックやAMMを使用するパスステップを示します。`currency`がXRPの場合は省略する必要があります。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `type` | 整数 | **廃止予定**_（省略可）_ 他にどのフィールドが指定されているかを示します。 |
|
||||
| `type_hex` | 文字列 | **廃止予定**: _（省略可）_`type`フィールドの16進数表現です。 |
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# トークン
|
||||
|
||||
XRP以外のすべての資産は、XRP Ledgerでは **トークン** として扱うことができます。通常のトークンは、アカウント間の[トラストライン](fungible-tokens/index.md) と呼ばれる関係で管理されます。すべてのアカウントは、トークンを保有することを許可する他のアカウントにあトークンを発行できますが、トークンを必要としないアカウントに一方的にトークンを配付することはできません。トークンは、台帳の外に存在する資産に裏付けられた「ステーブルコイン」、XRP Ledger上で独自に作成された純粋なデジタルトークン、コミュニティクレジットなど、様々な種類の価値を表すことが出来ます。
|
||||
XRP以外のすべての資産は、XRP Ledgerでは **トークン** として扱うことができます。通常のトークンは、アカウント間の[トラストライン](fungible-tokens/index.md) と呼ばれる関係で管理されます。すべてのアカウントは、トークンを保有することを許可する他のアカウントにはトークンを発行できますが、トークンを必要としないアカウントに一方的にトークンを配付することはできません。トークンは、台帳の外に存在する資産に裏付けられた「ステーブルコイン」、XRP Ledger上で独自に作成された純粋なデジタルトークン、コミュニティクレジットなど、様々な種類の価値を表すことが出来ます。
|
||||
|
||||
**注記:** XRP Ledger上のトークンは、過去に「IOUs」（[I-owe-you](https://en.wikipedia.org/wiki/IOU)の略）および「発行済み通貨」とも呼ばれてきました。しかし、これらの呼称は、XRP Ledgerのトークンが表すことのできるデジタル資産の全範囲をカバーしていないため、望ましくないとされています。<!-- STYLE_OVERRIDE: ious -->
|
||||
|
||||
|
||||
@@ -110,7 +110,7 @@ _`download_shard`メソッドは、権限のないユーザは実行できない
|
||||
|:----------|:-------|:--------------------------------------------------------|
|
||||
| `message` | 文字列 | このリクエストに対応して実行されたアクションを説明するメッセージ。 |
|
||||
|
||||
**ヒント:** サーバで使用可能なシャードを確認するには、[crawl_shardsメソッド[]を使用します。または、シャードストアーとして設定されたロケーションのサブフォルダー（`rippled.cfg`の`[shard_db]`の`path`パラメーター）を調べます。フォルダーには、シャードの番号に対応する名前が付いています。これらのフォルダーの1つに、シャードが未完了であることを示す`control.txt`ファイルが含まれていることがあります。
|
||||
**ヒント:** サーバで使用可能なシャードを確認するには、[crawl_shardsメソッド][]を使用します。または、シャードストアーとして設定されたロケーションのサブフォルダー（`rippled.cfg`の`[shard_db]`の`path`パラメーター）を調べます。フォルダーには、シャードの番号に対応する名前が付いています。これらのフォルダーの1つに、シャードが未完了であることを示す`control.txt`ファイルが含まれていることがあります。
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ CTID（トランザクション軽量識別子 / Compact Transaction Identifier
|
||||
|
||||
CTIDとトランザクションの[識別ハッシュ](../../../concepts/transactions/index.md#identifying-transactions)の違いは以下の通りです：
|
||||
|
||||
- CTIDは、ネットワークID、レジャーインデックス、レジャー内の位置に基づいて検証されたトランザクションを識別します。トランザクションがどのネットワークで検証されたかを特定するため、サイドチェーンへの接続など、複数のネットワークとやりとりする状況で使用できます。CTIDは64ビットで、通常は`C`で始まる16進数の大文字で、例えば`C005523E000000`のように記述します。
|
||||
- CTIDは、ネットワークID、レジャーインデックス、レジャー内の位置に基づいて検証されたトランザクションを識別します。トランザクションがどのネットワークで検証されたかを特定するため、サイドチェーンへの接続など、複数のネットワークとやりとりする状況で使用できます。CTIDは64ビットで、通常は`C`で始まる16進数の大文字で、例えば`C005523E00000000`のように記述します。
|
||||
- トランザクションの識別ハッシュは、そのトランザクションがどのチェーンで検証されたかに関係なく、その内容に基づいて署名されたトランザクションを識別します。これは暗号ハッシュであるため、トランザクションの内容が完全であることを証明するために使用することもできます。トランザクションハッシュは256ビットで、通常64文字の16進数で記述され、例えば`E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7`となります。
|
||||
|
||||
**注意:** 未検証のトランザクションにCTIDを使わないでください。トランザクションが最初に適用されたときと、コンセンサスプロセスによって検証されたときとで、トランザクションの正規順序が変わる可能性があります。
|
||||
|
||||
@@ -3,6 +3,8 @@ html: error-formatting.html
|
||||
parent: api-conventions.html
|
||||
seo:
|
||||
description: WebSocket、JSON-RPC、コマンドラインインターフェイスのエラーフォーマットと汎用エラーコードです。
|
||||
labels:
|
||||
- 開発
|
||||
---
|
||||
# エラーのフォーマット
|
||||
|
||||
@@ -16,7 +18,7 @@ seo:
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"id": 3,
|
||||
"status": "error",
|
||||
@@ -34,8 +36,9 @@ seo:
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```
|
||||
```json
|
||||
HTTP Status: 200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"error": "ledgerIndexMalformed",
|
||||
@@ -52,7 +55,7 @@ HTTP Status: 200 OK
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"error": "ledgerIndexMalformed",
|
||||
@@ -73,18 +76,19 @@ HTTP Status: 200 OK
|
||||
|
||||
## WebSocketフォーマット
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:---------|:------------------------------------------------------|
|
||||
| `id` | （場合により異なる） | このレスポンスのリクエスト元となったWeb Socketリクエストに指定されていたID |
|
||||
| `status` | 文字列 | `"error"`: リクエストが原因でエラーが発生した場合 |
|
||||
| `type` | 文字列 | 通常は`"response"`。これは、コマンドに対し正常にレスポンスしたことを示します。 |
|
||||
| `error` | 文字列 | 発生したエラータイプの一意のコード。 |
|
||||
| `request` | オブジェクト | このエラーが発生したリクエストのコピー（JSONフォーマット）。**注意:** リクエストにアカウントの機密情報が含まれている場合、ここにコピーされます。 |
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------------|:------|:------------------------------------------------------|
|
||||
| `id` | (多様) | このレスポンスのリクエスト元となったWeb Socketリクエストに指定されていたID |
|
||||
| `status` | 文字列 | `"error"`: リクエストが原因でエラーが発生した場合 |
|
||||
| `type` | 文字列 | 通常は`"response"`。これは、コマンドに対し正常にレスポンスしたことを示します。 |
|
||||
| `error` | 文字列 | 発生したエラータイプの一意のコード。 |
|
||||
| `request` | オブジェクト | このエラーが発生したリクエストのコピー（JSONフォーマット）。**注意:** リクエストにアカウントの機密情報が含まれている場合、ここにコピーされます。 |
|
||||
| `api_version` | 数値 | _(省略可)_ リクエストで`api_version`を指定していた場合は、その値。 |
|
||||
|
||||
|
||||
## JSON-RPCフォーマット
|
||||
|
||||
一部のJSON-RPCリクエストは、HTTPレイヤーでエラーコードでレスポンスします。この場合、レスポンスはレスポンス本文にプレーンテキストで記述されます。たとえば`method`パラメーターでコマンドを指定し忘れた場合、レスポンスは次のようになります。
|
||||
一部のJSON-RPCリクエストは、HTTPレイヤーでエラーコードでレスポンスします。この場合、レスポンスはレスポンス本文にプレーンテキストで記述されます。たとえば`method`パラメータでコマンドを指定し忘れた場合、レスポンスは次のようになります。
|
||||
|
||||
```
|
||||
HTTP Status: 400 Bad Request
|
||||
@@ -105,14 +109,19 @@ HTTPステータスコード200 OKが返されるその他のエラーの場合
|
||||
|
||||
すべてのメソッドは、以下のいずれかの値の`error`コードを返す可能性があります。
|
||||
|
||||
* `unknownCmd` - リクエストに、`rippled`サーバが認識する[コマンド](../index.md)が含まれていません。
|
||||
* `jsonInvalid` -（WebSocketのみ）リクエストは適切なJSONオブジェクトではありません。
|
||||
* この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
|
||||
* `missingCommand` -（WebSocketのみ）リクエストに`command`フィールドが指定されていませんでした。
|
||||
* この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
|
||||
* `tooBusy` - サーバの負荷が高すぎるため、現在このコマンドを実行できません。管理者として接続している場合は、通常このエラーが返されることはありません。
|
||||
* `noNetwork` - サーバとXRP Ledgerピアツーピアネットワークのその他の部分との接続で問題が発生しています（サーバがスタンドアロンモードで実行されていません）。
|
||||
* `noCurrent` - 高い負荷、ネットワークの問題、バリデータ障害、誤った構成、またはその他の問題が原因で、サーバが現行のレジャーを認識できません。
|
||||
* `noClosed` - サーバに決済済みレジャーがありません。通常、このエラーは起動が完了していないことが原因で発生します。
|
||||
* `wsTextRequired` -（WebSocketのみ）リクエストの[opcode](https://tools.ietf.org/html/rfc6455#section-5.2)がテキストではありません。
|
||||
* `amendmentBlocked` - サーバの状態が[Amendment blocked](../../../concepts/networks-and-servers/amendments.md#amendment-blocked)であるため、XRP Ledgerネットワークとの同期を維持するために最新バージョンに更新する必要があります。
|
||||
- `amendmentBlocked` - サーバの状態が[Amendmentブロック](../../../concepts/networks-and-servers/amendments.md#amendment-blocked)されたであるため、XRP Ledgerネットワークとの同期を維持するために最新バージョンに更新する必要があります。
|
||||
- `failedToForward` - ([レポートモード][]のサーバのみ)サーバはこのリクエストをP2Pモードサーバに転送しようとしましたが、接続に失敗しました。
|
||||
- `invalid_API_version` - サーバはリクエストの[APIバージョン番号](request-formatting.md#apiのバージョン管理)をサポートしていません。
|
||||
- `jsonInvalid` -（WebSocketのみ）リクエストは適切なJSONオブジェクトではありません。
|
||||
- この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
|
||||
- `missingCommand` -（WebSocketのみ）リクエストに`command`フィールドが指定されていませんでした。
|
||||
- この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
|
||||
- `noClosed` - サーバに閉鎖済みレジャーがありません。通常、このエラーは起動が完了していないことが原因で発生します。
|
||||
- `noCurrent` - 高い負荷、ネットワークの問題、バリデータ障害、誤った構成、またはその他の問題が原因で、サーバが現行のレジャーを認識できません。
|
||||
- `noNetwork` - サーバとXRP Ledgerピアツーピアネットワークのその他の部分との接続で問題が発生しています（サーバがスタンドアロンモードで実行されていません）。
|
||||
- `unknownCmd` - リクエストに、`rippled`サーバが認識する[コマンド](../index.md)が含まれていません。
|
||||
- `tooBusy` - サーバの負荷が高すぎるため、現在このコマンドを実行できません。管理者として接続している場合は、通常このエラーが返されることはありません。
|
||||
- `wsTextRequired` -（WebSocketのみ）リクエストの[opcode](https://tools.ietf.org/html/rfc6455#section-5.2)がテキストではありません。
|
||||
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -6,71 +6,135 @@ seo:
|
||||
---
|
||||
# リクエストのフォーマット
|
||||
|
||||
## WebSocketフォーマット
|
||||
|
||||
`rippled`サーバへのWebSocketを開いた後、以下の属性を使用して、コマンドを[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信できます。
|
||||
|
||||
* コマンド名を最上位の`"command"`フィールドに指定します。
|
||||
* このコマンドのすべての関連パラメーターも最上位に指定します。
|
||||
* オプションで、任意の値を指定した`"id"`フィールドを指定します。このリクエストへのレスポンスでは、同一の`"id"`フィールドを使用します。そうすることで、レスポンスが順不同で到達した場合も、どのリクエストによってどのレスポンスを得られたのかがわかります。
|
||||
|
||||
レスポンスはJSONオブジェクトとして返されます。
|
||||
|
||||
## JSON-RPCフォーマット
|
||||
|
||||
JSON-RPCリクエストを実行するには、`rippled`サーバがJSON-RPC接続をリッスンしているポートおよびIPで、HTTP **POST**リクエストをルートパス（`/`）に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティ上の理由から、`rippled`ではSSL v3以前を _サポートしていません_ 。
|
||||
|
||||
常に`Content-Type`ヘッダー（値`application/json`）を指定してください。
|
||||
|
||||
複数のリクエストを実行する予定の場合は、リクエスト間で接続を閉じてから開く操作を行わずに済むように、[Keep-Alives](http://tools.ietf.org/html/rfc7230#section-6.3)を使用してください。
|
||||
|
||||
以下の属性を指定したリクエスト本文を[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信します。
|
||||
|
||||
* コマンドを最上位の`"method"` フィールドに指定します。
|
||||
* 最上位の`"params"`フィールドを指定します。このフィールドの内容は、コマンドのすべてのパラメーターが指定された1つの入れ子JSONオブジェクトのみを保持している**1要素配列**です。
|
||||
|
||||
レスポンスもJSONオブジェクトです。
|
||||
|
||||
## コマンドライン形式
|
||||
|
||||
コマンドラインでは、通常の（ダッシュが先頭に付いた）コマンドラインオプションの後にコマンドを指定し、その後に一連の限定的なパラメーターをスペースで区切って指定します。スペースやその他の特殊文字が含まれている可能性のあるパラメーター値は、一重引用符で囲みます。
|
||||
|
||||
### リクエストの例
|
||||
## リクエストの例
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
"command": "account_info",
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated"
|
||||
"id": 2,
|
||||
"command": "account_info",
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated",
|
||||
"api_version": 1
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```
|
||||
```json
|
||||
POST http://s1.ripple.com:51234/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "account_info",
|
||||
"params": [
|
||||
{
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
]
|
||||
"method": "account_info",
|
||||
"params": [
|
||||
{
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated",
|
||||
"api_version": 1
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```
|
||||
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
|
||||
```sh
|
||||
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated strict
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## WebSocketフォーマット
|
||||
|
||||
`rippled`サーバへのWebSocketを開いた後、以下のフィールドを使用して、コマンドを[JSON](https://ja.wikipedia.org/wiki/JSON)オブジェクトとして送信できます。
|
||||
|
||||
| フィールド | 型 | 説明 |
|
||||
|:--------------------|:----------|:-------------------------------------------|
|
||||
| `command` | 文字列 | [APIメソッド](../public-api-methods/index.md)の名前。 |
|
||||
| `id` | (多種) | _(省略可)_ リクエストを識別するための一意な値。このリクエストに対するレスポンスも同じ `id` フィールドを使用します。これにより、レスポンスが順番通りに返ってこない場合でも、どのリクエストがどのレスポンスを返したのかを知ることができます。 |
|
||||
| `api_version` | 数値 | _(省略可)_ 使用するAPIのバージョン。省略時はバージョン1を使用します。詳細については、[APIのバージョン管理](#api-versioning)をご覧ください。 |
|
||||
| (メソッドのパラメータ) | (多種) | トップレベルのメソッドに任意のパラメータを指定します。 |
|
||||
|
||||
サーバからのレスポンスについては[レスポンスのフォーマット](response-formatting.md)をご覧ください。
|
||||
|
||||
## JSON-RPCフォーマット
|
||||
|
||||
JSON-RPCリクエストを実行するには、`rippled`サーバがJSON-RPC接続をリッスンしているポートおよびIPで、HTTP **POST**リクエストをルートパス（`/`）に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティ上の理由から、`rippled`ではSSL v3以前を _サポートしていません_ 。
|
||||
|
||||
`Content-Type`ヘッダ(値`application/json`)を常に指定してください。
|
||||
|
||||
複数のリクエストを実行する場合は、リクエスト間で再接続を行わずに済むように、[Keep-Alives](http://tools.ietf.org/html/rfc7230#section-6.3)を使用してください。
|
||||
|
||||
以下のフィールドを指定したリクエストボディを[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信します。
|
||||
|
||||
|
||||
| フィールド | 型 | 説明 |
|
||||
|:--------------------|:----------|:-------------------------------------------|
|
||||
| `method` | 文字列 | [APIメソッド](../public-api-methods/index.md)の名前。 |
|
||||
| `params` | 配列 | _(省略可)_ このメソッドのパラメータを持つネストされたJSONオブジェクトを含む**一要素の配列**。メソッドがパラメータを必要としない場合は、このフィールドを省略できます。 |
|
||||
|
||||
`params`配列内のオブジェクトには以下のフィールドを含めることができます。
|
||||
|
||||
| フィールド | 型 | 説明 |
|
||||
|:--------------------|:----------|:-------------------------------------------|
|
||||
| `api_version` | 数値 | _(省略可)_ 使用するAPIのバージョン。省略時はバージョン1を使用します。詳細については、[APIのバージョン管理](#api-versioning)をご覧ください。 |
|
||||
| (Method Parameters) | (多種) | メソッドで利用する任意のパラメータ。 |
|
||||
|
||||
サーバからのレスポンスについては[レスポンスのフォーマット](response-formatting.md)をご覧ください。
|
||||
|
||||
## コマンドライン形式
|
||||
|
||||
APIのメソッド名は、通常の(ダッシュで始まる)コマンドラインオプションの後に、スペースで区切られた一部のパラメータを続けて指定します。スペースやその他の特殊文字を含む可能性のあるパラメータ値については、シングルクォートで囲んでください。すべてのメソッドがコマンドラインAPI構文を持っているわけではありません。詳しくは、[コマンドラインの使い方](../../../infrastructure/commandline-usage.md#client-mode-options)をご覧ください。
|
||||
|
||||
コマンドラインはJSON-RPCを呼び出すため、そのレスポンスは常にJSON-RPCの[レスポンスのフォーマット](response-formatting.md)と一致します。
|
||||
|
||||
コマンドラインは常に最新の[APIバージョン](#api-versioning)を使用します。
|
||||
|
||||
**注意:** コマンドラインインターフェイスは管理目的でのみ使用することを意図しており、_サポートされているAPIではありません_です。新しいバージョンの`rippled`では、警告なしにコマンドラインAPIに破壊的な変更が導入される可能性があります！
|
||||
|
||||
|
||||
## APIのバージョン管理
|
||||
|
||||
`rippled`サーバは、使用するAPIバージョンを識別するために単一の整数を使用します。現在、`1`と`2`{% badge href="https://github.com/XRPLF/rippled/releases/tag/2.0.0" %}新規: rippled 2.0.0{% /badge %}の2つのAPIバージョンがあります。サーバは`version`APIメソッドでサポートされるAPIバージョンの範囲を報告します。<!-- TODO: add a link when `version` method is documented. -->
|
||||
|
||||
それぞれのAPIバージョンは、破壊的な変更が導入されるときに新しいAPIバージョン番号を導入します。プレリリースやベータ、開発バージョンでは、同じAPIバージョン番号で破壊的な変更を導入することがあり、`account_tx`リクエストを使用してAPIバージョン2を使用し、同じ接続でAPIバージョン1を使用して別の`account_tx`リクエストを行うことができます。
|
||||
|
||||
将来の`rippled`のバージョンで破壊的な変更が導入されると、新しいAPIバージョン3が導入されます。
|
||||
|
||||
|
||||
### 破壊的変更
|
||||
|
||||
次の種類の変更は**破壊的変更**です。
|
||||
|
||||
- リクエストやレスポンスのフィールドの削除や名前の変更
|
||||
- リクエストやレスポンスのフィールドの型の変更
|
||||
- リクエストやレスポンスのフィールドの意味の変更
|
||||
- リクエストやレスポンスのフィールドの位置の変更、または他のリクエストやレスポンスのフィールドの前への新しいフィールドの追加
|
||||
- APIメソッドの削除や名前の変更
|
||||
- 既存のクライアントから確認できるAPI関数の動作の変更
|
||||
- 次の種類の変更は、gRPC APIにのみ適用されます。
|
||||
- `proto`フィールド番号の変更
|
||||
- 列挙型または列挙型値の削除または名前の変更
|
||||
- `oneof`からのフィールドの追加または削除
|
||||
- `oneof`の分割または統合
|
||||
- メッセージフィールドが`optional`、`repeated`、または`required`であるかの変更
|
||||
- リクエストまたはレスポンスのストリーム値の変更
|
||||
- パッケージまたはサービスの削除または名前の変更
|
||||
|
||||
フルリリースで破壊的変更が加えられると、新しいAPIバージョン番号が導入されます。プレリリース版、ベータ版、開発版では、同じAPIバージョン番号に変更を加えることがあります。
|
||||
|
||||
### 非破壊的変更
|
||||
|
||||
次の種類の変更は**非破壊的変更**であり、APIバージョン番号の変更なしに発生する可能性があります。
|
||||
|
||||
- パラメータの位置の変更を含まない、新しいフィールドの追加
|
||||
- 新しいAPIメソッドの追加
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -6,17 +6,20 @@ seo:
|
||||
---
|
||||
# レスポンスのフォーマット
|
||||
|
||||
`rippled` APIからのレスポンスのフォーマットは、メソッドが呼び出されたインターフェイス（WebSocket、JSON-RPC、コマンドライン）に応じて多少異なります。コマンドラインインターフェイスがJSON-RPCを呼び出すため、コマンドラインインターフェイスとJSON-RPCインターフェイスは同じフォーマットを使用します。
|
||||
`rippled`APIからのレスポンスのフォーマットは、メソッドが呼び出されたインターフェイス（WebSocket、JSON-RPC、コマンドライン）に応じて多少異なります。コマンドラインインターフェイスがJSON-RPCを呼び出すため、コマンドラインインターフェイスとJSON-RPCインターフェイスは同じフォーマットを使用します。
|
||||
|
||||
成功した場合のレスポンスに含まれるフィールドは、以下の通りです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------------|:---------|:------------------------------------------------|
|
||||
| `id` | （場合により異なる） | （WebSocketのみ）このレスポンスのリクエスト元となったリクエストで指定されているID。 |
|
||||
| `status` | 文字列 | （WebSocketのみ）値が`success`である場合、リクエストがサーバによって正常に受信され、理解されたことを示します。 |
|
||||
| `result.status` | 文字列 | （JSON-RPCおよびコマンドライン）値が`success`である場合、リクエストがサーバによって正常に受信され、理解されたことを示します。 |
|
||||
| `type` | 文字列 | （WebSocketのみ）値が`response`の場合、コマンドに対する正常なレスポンスであることを示します。[非同期の通知](../public-api-methods/subscription-methods/subscribe.md)では、`ledgerClosed`や`transaction`など異なる値が使用されます。 |
|
||||
| `result` | オブジェクト | クエリーの結果。内容はコマンドによって異なります。 |
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------------|:-----------|:------------------------------------------------|
|
||||
| `id` | （場合により異なる） | （WebSocketのみ）このレスポンスのリクエスト元となったリクエストで指定されているID。 |
|
||||
| `status` | 文字列 | （WebSocketのみ）値が`success`である場合、リクエストがサーバによって正常に受信され、理解されたことを示します。 |
|
||||
| `result.status` | 文字列 | （JSON-RPCおよびコマンドライン）値が`success`である場合、リクエストがサーバによって正常に受信され、理解されたことを示します。 |
|
||||
| `type` | 文字列 | （WebSocketのみ）値が`response`の場合、コマンドに対する正常なレスポンスであることを示します。[非同期の通知](../public-api-methods/subscription-methods/subscribe.md)では、`ledgerClosed`や`transaction`など異なる値が使用されます。 |
|
||||
| `result` | オブジェクト | クエリーの結果。内容はコマンドによって異なります。 |
|
||||
| `warning` | 文字列 | _(省略可)_ このフィールドが存在する場合、値は文字列`load`です。これはクライアントがサーバがこのクライアントを切断する[レートリミット](rate-limiting.md)の閾値に近づいていることを意味します。 |
|
||||
| `warnings` | 配列 | _(省略可)_ このフィールドが存在する場合、重要な警告を含む1つ以上の**Warningsオブジェクト**が含まれます。詳細については、[API警告](#apiの警告)をご覧ください。 |
|
||||
| `forwarded` | 真偽値 | _(省略可)_ `true`の場合、このリクエストとレスポンスは[レポートモード][]サーバからP2Pモードサーバに転送されます。デフォルトは`false`です。 |
|
||||
|
||||
|
||||
## 成功した場合のレスポンスの例
|
||||
@@ -24,32 +27,33 @@ seo:
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6760970
|
||||
}
|
||||
"id": 2,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6760970
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```
|
||||
```json
|
||||
HTTP Status: 200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
@@ -71,7 +75,7 @@ HTTP Status: 200 OK
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
@@ -93,3 +97,102 @@ HTTP Status: 200 OK
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## APIの警告
|
||||
|
||||
レスポンスに`warnings`の配列が含まれる場合、その配列の各要素はサーバからの個別の警告を表します。このような**警告オブジェクト**はそれぞれ以下のフィールドを含みます：
|
||||
|
||||
| フィールド | 型 | 説明 |
|
||||
|:----------|:-----------|:--------------------------------------------------------|
|
||||
| `id` | 数値 | この警告メッセージの一意の数値コード。 |
|
||||
| `message` | 文字列 | このメッセージの原因を説明する人間が読める文字列。このメッセージの内容に依存するようなソフトウェアを書かないでください。代わりに`id`(および`details`(もしあれば))を使って警告を識別してください。 |
|
||||
| `details` | オブジェクト | _(省略可)_ この警告に関する追加情報。内容は警告の種類によって異なります。 |
|
||||
|
||||
以下の資料では、考えられるすべての警告について説明しています。
|
||||
|
||||
### 1001. Unsupported amendments have reached majority
|
||||
|
||||
警告の例:
|
||||
|
||||
```json
|
||||
"warnings" : [
|
||||
{
|
||||
"details" : {
|
||||
"expected_date" : 864030,
|
||||
"expected_date_UTC" : "2000-Jan-11 00:00:30.0000000 UTC"
|
||||
},
|
||||
"id" : 1001,
|
||||
"message" : "One or more unsupported amendments have reached majority. Upgrade to the latest version before they are activated to avoid being amendment blocked."
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
この警告は、XRP Ledgerプロトコルの1つ以上の[Amendment](../../../concepts/networks-and-servers/amendments.md)が有効になる予定であるが、現在のサーバにはそれらのAmendmentの実装がないことを示しています。これらのAmendmentが有効になると、現在のサーバは[Amendmentブロック](../../../concepts/networks-and-servers/amendments.md#amendment-blocked-servers)されるため、できるだけ早く[最新の`rippled`バージョンにアップグレード](../../../infrastructure/installation/index.md)する必要があります。
|
||||
|
||||
サーバは、この警告を送信するのは、クライアントが[管理者として接続している](../../../tutorials/http-websocket-apis/build-apps/get-started.md#admin-access)場合のみです。
|
||||
|
||||
この警告には、以下のフィールドを含む`details`フィールドが含まれます。
|
||||
|
||||
| フィールド | 型 | 説明 |
|
||||
|:--------------------|:-------|:----------------------------------------------|
|
||||
| `expected_date` | 数値 | サポートされていない最初のAmendmentが有効になると予想される時刻([リップルエポックからの秒数][])。|
|
||||
| `expected_date_UTC` | 文字列 | サポートされていない最初のAmendmentが有効になると予想される時刻(UTCでのタイムスタンプ)。 |
|
||||
|
||||
レジャーのクローズ時間の変動により、これらはおおよその時刻となります。また、指定された時刻までにAmendmentが80%以上のバリデータからサポートされ続けない場合、Amendmentが有効にならず、期待された時刻にAmendmentが有効にならない可能性があります。サポートされていないAmendmentが有効にならない限り、サーバはAmendmentブロックされません。
|
||||
|
||||
|
||||
### 1002. This server is amendment blocked
|
||||
|
||||
警告の例:
|
||||
|
||||
```json
|
||||
"warnings" : [
|
||||
{
|
||||
"id" : 1002,
|
||||
"message" : "This server is amendment blocked, and must be updated to be able to stay in sync with the network."
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
この警告は、サーバが[Amendmentブロック](../../../concepts/networks-and-servers/amendments.md)され、同期を取ることができなくなったことを示しています。
|
||||
|
||||
サーバの管理者は、アクティブ化されたAmendmentをサポートするバージョンに[`rippled`をアップグレード](../../../infrastructure/installation/index.md)する必要があります。
|
||||
|
||||
### 1003. This is a reporting server
|
||||
|
||||
警告の例:
|
||||
|
||||
```json
|
||||
"warnings" : [
|
||||
{
|
||||
"id" : 1003,
|
||||
"message" : "This is a reporting server. The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
この警告は、リクエストに応答するサーバが[レポートモード][]で実行されていることを示しています。レポートモードはピアツーピアネットワークに接続せず、まだ検証されていないレジャーデータを追跡しないため、一部のAPIメソッドが利用できないか、異なる動作をすることがあります。
|
||||
|
||||
一般的に、この警告は無視しても安全です。
|
||||
|
||||
**注意:** レポートモードで検証されていないデータをリクエストする場合、明示的に[レジャーバージョンを指定][レジャーの指定]しない限り、レポートモードはデフォルトで最新の検証済みレジャーを使用します。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [リクエストのフォーマット](request-formatting.md)
|
||||
- [エラーのフォーマット](error-formatting.md): APIレスポンスの失敗
|
||||
- **コンセプト:**
|
||||
- [`rippled`サーバ](../../../concepts/networks-and-servers/index.md)
|
||||
- [コンセンサス](../../../concepts/consensus-protocol/index.md)
|
||||
- [Amendment](../../../concepts/networks-and-servers/amendments.md)
|
||||
- [既知のAmendment](/resources/known-amendments.md)
|
||||
- **チュートリアル:**
|
||||
- [XRP LedgerのAPIを触ってみよう](../../../tutorials/http-websocket-apis/build-apps/get-started.md)
|
||||
- [`rippled`のインストールと更新](../../../infrastructure/installation/index.md)
|
||||
- **リファレンス:**
|
||||
- [featureメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -14,16 +14,17 @@ labels:
|
||||
|
||||
アカウントの`account_objects`レスポンスに含まれる可能性のあるオブジェクトのタイプには以下のものがあります。
|
||||
|
||||
- [Offerエントリ](../../../protocol/ledger-data/ledger-entry-types/offer.md): 現在処理中であり、資金化されていない、または有効期限切れで削除されていない注文情報。（詳細は、[オファーのライフサイクル](../../../../concepts/tokens/decentralized-exchange/offers.md#オファーのライフサイクル)をご覧ください。）
|
||||
- [RippleStateエントリ](../../../protocol/ledger-data/ledger-entry-types/ripplestate.md): このアカウント側がデフォルト状態にないトラストライン。
|
||||
- アカウントの[SignerList](../../../protocol/ledger-data/ledger-entry-types/signerlist.md): アカウントで[マルチシグ](../../../../concepts/accounts/multi-signing.md)が有効な場合。
|
||||
- [Escrowエントリ](../../../../concepts/payment-types/escrow.md): 実行されていないかまたはキャンセルされていない保留中の支払い。
|
||||
- [PayChannelエントリ](../../../protocol/ledger-data/ledger-entry-types/paychannel.md): 現在開いているペイメントチャネル。
|
||||
- [Bridgeエントリ](../../../protocol/ledger-data/ledger-entry-types/bridge.md): クロスチェーンブリッジ向けs. _([XChainBridge amendment][]が必要です {% not-enabled /%})_
|
||||
- [Checkエントリ](../../../protocol/ledger-data/ledger-entry-types/check.md): 保留中のCheck。
|
||||
- [DepositPreauthエントリ](../../../protocol/ledger-data/ledger-entry-types/depositpreauth.md): 入金の事前承認。
|
||||
- [Ticketエントリ](../../../../concepts/accounts/tickets.md): Ticket情報。
|
||||
- [Escrowエントリ](../../../../concepts/payment-types/escrow.md): 実行されていないかまたはキャンセルされていない保留中の支払い。
|
||||
- [NFTokenOfferエントリ](../../../protocol/ledger-data/ledger-entry-types/nftokenoffer.md): NFTを購入・売却するためのオファー。
|
||||
- [NFTokenPageエントリ](../../../protocol/ledger-data/ledger-entry-types/nftokenpage.md): NFTの集合。 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.11.0" %}新規: rippled 1.11.0{% /badge %}
|
||||
- [Offerエントリ](../../../protocol/ledger-data/ledger-entry-types/offer.md): 現在処理中であり、資金化されていない、または有効期限切れで削除されていない注文情報。（詳細は、[オファーのライフサイクル](../../../../concepts/tokens/decentralized-exchange/offers.md#オファーのライフサイクル)をご覧ください。）
|
||||
- [PayChannelエントリ](../../../protocol/ledger-data/ledger-entry-types/paychannel.md): 現在開いているペイメントチャネル。
|
||||
- [RippleStateエントリ](../../../protocol/ledger-data/ledger-entry-types/ripplestate.md): このアカウント側がデフォルト状態にないトラストライン。
|
||||
- アカウントの[SignerList](../../../protocol/ledger-data/ledger-entry-types/signerlist.md): アカウントで[マルチシグ](../../../../concepts/accounts/multi-signing.md)が有効な場合。
|
||||
- [Ticketエントリ](../../../../concepts/accounts/tickets.md): Ticket情報。
|
||||
|
||||
|
||||
## リクエストのフォーマット
|
||||
@@ -81,7 +82,7 @@ rippled account_objects r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated
|
||||
| `ledger_index` | [レジャーインデックス][] | いいえ | 使用するレジャーの[レジャーインデックス][]、またはレジャーを自動的に選択するためのショートカット文字列。（[レジャーの指定][]ををご覧ください） |
|
||||
| `limit` | 符号なし整数 | いいえ | 結果に含めることができるオブジェクトの最大数。非管理者接続では10以上400以下の範囲で値を指定する必要があります。デフォルトでは200です。 |
|
||||
| `marker` | [マーカー][] | いいえ | 以前にページネーションされたレスポンスの値。そのレスポンスを停止した箇所からデータの取得を再開します。 |
|
||||
| `type` | 文字列 | いいえ | 指定されている場合、結果をフィルタリングしてこのタイプのレジャーオブジェクトのみが含まれるようにします。有効なタイプは`check`、`deposit_preauth`、`escrow`、`offer`、`payment_channel`、`signer_list`、`state`（トラストライン）そして`ticket`です。 |
|
||||
| `type` | 文字列 | いいえ | 指定されている場合、結果をフィルタリングしてこのタイプのレジャーオブジェクトのみが含まれるようにします。有効なタイプは`bridge`, `check`、`deposit_preauth`、`escrow`、`nft_offer`, `nft_page`, `offer`、`payment_channel`、`signer_list`、`state`（トラストライン）そして`ticket`です。 |
|
||||
|
||||
**注記:** `account_objects`コマンドのコマンドラインインタフェースは`type`フィールドを受け付けません。代わりにコマンドラインでJSON-RPC形式のリクエストを送信するには[jsonメソッド][]を使用してください。
|
||||
|
||||
|
||||
@@ -4,8 +4,8 @@ parent: account-methods.html
|
||||
seo:
|
||||
description: 指定したアカウントに関連するトランザクションのリストを取得します。
|
||||
labels:
|
||||
- Accounts
|
||||
- Payments
|
||||
- アカウント
|
||||
- 支払い
|
||||
---
|
||||
# account_tx
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/AccountTx.cpp "Source")
|
||||
@@ -23,7 +23,7 @@ labels:
|
||||
{
|
||||
"id": 2,
|
||||
"command": "account_tx",
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"ledger_index_min": -1,
|
||||
"ledger_index_max": -1,
|
||||
"binary": false,
|
||||
@@ -39,7 +39,7 @@ labels:
|
||||
"method": "account_tx",
|
||||
"params": [
|
||||
{
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"binary": false,
|
||||
"forward": false,
|
||||
"ledger_index_max": -1,
|
||||
@@ -53,8 +53,9 @@ labels:
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```sh
|
||||
#Syntax account_tx account ledger_index_min ledger_index_max [offset] [limit] [binary] [count] [forward]
|
||||
rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 5 1 0 1
|
||||
# Syntax: account_tx account [ledger_index_min [ledger_index_max]] [limit] [offset] [binary] [count] [descending]
|
||||
# For binary/count/descending, use the parameter name for true and omit for false.
|
||||
rippled -- account_tx rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w -1 -1 2 0 binary descending
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
@@ -66,19 +67,20 @@ rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 5 1 0 1
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-------------------|:-------------------------------------------|:-----------|
|
||||
| `account` | 文字列 | アカウントの一意のIDであり、最も一般的にはアカウントのアドレスが使用されます。 |
|
||||
| `ledger_index_min` | 整数 | _（省略可能）_ 含めるトランザクションのレジャーのうち最古のものを指定するのに使用します。`-1`の値は、使用可能な検証済みレジャーのうち最古のバージョンを使用するよう、サーバに指示します。 |
|
||||
| `ledger_index_max` | 整数 | _（省略可能）_ 含めるトランザクションのレジャーのうち最新のものを指定するのに使用します。`-1`の値は、使用可能な検証済みレジャーのうち最新のバージョンを使用するよう、サーバに指示します。 |
|
||||
| `ledger_hash` | 文字列 | _（省略可能）_ 単一のレジャーからのみトランザクションを検索するのに使用します。（[レジャーの指定][]をご覧ください） |
|
||||
| `account` | 文字列 | アカウントの一意のIDであり、最も一般的なアカウントのアドレスが使用されます。 |
|
||||
| `tx_type` | 文字列 | _(省略可)_ **Clioのみ** "Clawback"、"AccountSet"、"AccountDelete "など、特定のタイプのトランザクションのみを返します。 See [Transaction Types](../../../../references//protocol/transactions/types/index.md#transaction-types). [新規: Clio v2.0](https://github.com/XRPLF/clio/releases/tag/2.0.0 "BADGE_BLUE") [AMMのサポート: Clio v2.1.0](https://github.com/XRPLF/clio/releases/tag/2.1.0 "BADGE_GREEN") |
|
||||
| `ledger_index_min` | 整数 | [API v1][]: _（省略可能）_ 含めるトランザクションのレジャーのうち最古のものを指定するのに使用します。`-1`の値は、使用可能な検証済みレジャーのうち最古のバージョンを使用するよう、サーバに指示します。<br>[API v2][]: v1と同じですが、サーバが持つレジャーの範囲を超えて値を指定すると`lgrIdxMalformed`エラーを返します。 |
|
||||
| `ledger_index_max` | 整数 | _（省略可能）_ 含めるトランザクションのレジャーのうち最新のものを指定するのに使用します。`-1`の値は、使用可能な検証済みレジャーのうち最新のバージョンを使用するよう、サーバに指示します。<br>[API v2][]: v1と同じですが、サーバが持つレジャーの範囲を超えて値を指定すると`lgrIdxMalformed`エラーを返します。 |
|
||||
| `ledger_hash` | 文字列 | [API v1][]: _（省略可能）_ 単一のレジャーからのみトランザクションを検索するのに使用します。（[レジャーの指定][]をご覧ください） |
|
||||
| `ledger_index` | 文字列または符号なし整数 | _（省略可能）_ 単一のレジャーからのみトランザクションを検索するのに使用します。（[レジャーの指定][]をご覧ください） |
|
||||
| `binary` | ブール値 | _（省略可能）_ デフォルトは`false`です。`true`に設定すると、JSONの代わりに16進文字列でトランザクションが返されます。 |
|
||||
| `forward` | ブール値 | _（省略可能）_ デフォルトは`false`です。`true`に設定すると、最も古いレジャーを先頭としてインデックスが付けられた値が返されます。そうしない場合、最新のレジャーを先頭として結果にインデックスが付けられます。（結果を示した各ページの中身は順序よく整理されていない場合がありますが、ページ全体としては順序付けされています。） |
|
||||
| `binary` | ブール値 | [API v1][]: _（省略可能）_ デフォルトは`false`です。`true`に設定すると、JSONの代わりに16進文字列でトランザクションが返されます。<br>[API v2][]: v1と同じですが、 真偽値以外の値を指定すると`invalidParams`エラーを返します。 |
|
||||
| `forward` | ブール値 | [API v1][]: _（省略可能）_ デフォルトは`false`です。`true`に設定すると、最も古いレジャーを先頭としてインデックスが付けられた値が返されます。そうしない場合、最新のレジャーを先頭として結果にインデックスが付けられます。（結果を示した各ページの中身は順序よく整理されていない場合がありますが、ページ全体としては順序付けされています。）<br>[API v2][]: v1と同じですが、 真偽値以外の値を指定すると`invalidParams`エラーを返します。 |
|
||||
| `limit` | 整数 | _（省略可能）_ デフォルトは変化します。取得するトランザクションの数を制限します。サーバはこの値を受け入れる必要はありません。 |
|
||||
| `marker` | [マーカー][] | 以前にページネーションされたレスポンスの値。そのレスポンスを停止した箇所からデータの取得を再開します。サーバが使用できるレジャーの範囲に変更があっても、この値は変わりません。 |
|
||||
|
||||
次の各フィールドは省略可能とされていますが、リクエスト内で**1つ以上は使用する必要があります**: `ledger_index`、`ledger_hash`、`ledger_index_min`、または`ledger_index_max`。
|
||||
- リクエスト内で次の各フィールドのうち1つ以上を使用する必要があります: `ledger_index`、`ledger_hash`、`ledger_index_min`、または`ledger_index_max`。
|
||||
- [API v2]： `ledger_index` と `ledger_hash` のどちらかを指定した場合、`ledger_index_min` と `ledger_index_max` を含めると `invalidParams` エラーが返ります。
|
||||
|
||||
次のフィールドは廃止されました： `offset`、`count`、`descending`、`ledger_max`、`ledger_min`。 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}削除: rippled 1.7.0{% /badge %}
|
||||
|
||||
### 照会されたデータの繰り返し
|
||||
|
||||
@@ -95,14 +97,167 @@ rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 5 1 0 1
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"id": 2,
|
||||
"result": {
|
||||
"account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"ledger_index_max": 57111999,
|
||||
"ledger_index_min": 55886305,
|
||||
"limit": 2,
|
||||
"marker": {
|
||||
"ledger": 57111981,
|
||||
"seq": 16
|
||||
},
|
||||
"transactions": [
|
||||
{
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"Balance": "3732969177079",
|
||||
"Flags": 131072,
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 702817
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
|
||||
"PreviousFields": {
|
||||
"Balance": "3713891690008"
|
||||
},
|
||||
"PreviousTxnID": "D58864C16344ADCC15995C7986CFC607CB693E88F84D2E019F0A35FB29749202",
|
||||
"PreviousTxnLgrSeq": 57111994
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
|
||||
"Balance": "40010160",
|
||||
"Flags": 131072,
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 466334
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9",
|
||||
"PreviousFields": {
|
||||
"Balance": "19117497271",
|
||||
"Sequence": 466333
|
||||
},
|
||||
"PreviousTxnID": "F6B8274D3D419A95A59681E5F55578084C395FF9051924360CA3EA745F5581E8",
|
||||
"PreviousTxnLgrSeq": 57111993
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 25,
|
||||
"TransactionResult": "tesSUCCESS",
|
||||
"delivered_amount": "19077487071"
|
||||
},
|
||||
"tx": {
|
||||
"Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
|
||||
"Amount": "19077487071",
|
||||
"Destination": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"DestinationTag": 1,
|
||||
"Fee": "40",
|
||||
"Flags": 2147483648,
|
||||
"LastLedgerSequence": 57112020,
|
||||
"Sequence": 466333,
|
||||
"SigningPubKey": "0381575032E254BF4D699C3D8D6EFDB63B3A71F97475C6F6885BC7DAEEE55D9A01",
|
||||
"TransactionType": "Payment",
|
||||
"TxnSignature": "3045022100CFC5FD057C7C685C690637AD1E639E2642BBC00EFD8E06E3F6C72FA924BC99D40220317D0708E814F69F874D641B6732E37A53B1220B493B2B8390D9EF51E8062515",
|
||||
"date": 649200260,
|
||||
"hash": "46BF0B576677B0DEA2D94591424A57A2DE8E3D89383631E16F40D09A513C656C",
|
||||
"inLedger": 57111998,
|
||||
"ledger_index": 57111998
|
||||
},
|
||||
"validated": true
|
||||
},
|
||||
{
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"Balance": "3713891690008",
|
||||
"Flags": 131072,
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 702817
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
|
||||
"PreviousFields": {
|
||||
"Balance": "3714441690048",
|
||||
"Sequence": 702816
|
||||
},
|
||||
"PreviousTxnID": "FDD5007913B39027BAF10B31144DBC1F7DC147528DF31FF048A06DC5D3108BD6",
|
||||
"PreviousTxnLgrSeq": 57111981
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9dU6Z7P2i7MrDi1VUZ7uyq6J77eg86YtB",
|
||||
"Balance": "2629998983",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 10
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "27B96FE681B33825CC95DA197358B30D3A1721F2125F2D76022D46B2418ABA0A",
|
||||
"PreviousFields": {
|
||||
"Balance": "2079998983"
|
||||
},
|
||||
"PreviousTxnID": "44A47AC04C0C7237C32BE9A532B578D07641705D3A59DB9B3C5B6225001E39B7",
|
||||
"PreviousTxnLgrSeq": 56613857
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 16,
|
||||
"TransactionResult": "tesSUCCESS",
|
||||
"delivered_amount": "550000000"
|
||||
},
|
||||
"tx": {
|
||||
"Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"Amount": "550000000",
|
||||
"Destination": "r9dU6Z7P2i7MrDi1VUZ7uyq6J77eg86YtB",
|
||||
"Fee": "40",
|
||||
"Flags": 2147483648,
|
||||
"LastLedgerSequence": 57112016,
|
||||
"Sequence": 702816,
|
||||
"SigningPubKey": "020A46D8D02AC780C59853ACA309EAA92E7D8E02DD72A0B6AC315A7D18A6C3276A",
|
||||
"TransactionType": "Payment",
|
||||
"TxnSignature": "3045022100D589029EF63F9E528F6100C7A36D26AFFF84085EC9AC16DA8E30E11F390D4E87022011466E0FE4A90B89142EE47E535545EEA4A2D65E0BD234DFB447721218B59C9B",
|
||||
"date": 649200241,
|
||||
"hash": "D58864C16344ADCC15995C7986CFC607CB693E88F84D2E019F0A35FB29749202",
|
||||
"inLedger": 57111994,
|
||||
"ledger_index": 57111994
|
||||
},
|
||||
"validated": true
|
||||
}
|
||||
],
|
||||
"validated": true
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
200 OK
|
||||
{
|
||||
"result": {
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"ledger_index_max": 6542489,
|
||||
"ledger_index_min": 32570,
|
||||
"account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"ledger_index_max": 57112019,
|
||||
"ledger_index_min": 56248229,
|
||||
"limit": 2,
|
||||
"marker": {
|
||||
"ledger": 57112007,
|
||||
"seq": 13
|
||||
},
|
||||
"status": "success",
|
||||
"transactions": [
|
||||
{
|
||||
"meta": {
|
||||
@@ -110,109 +265,61 @@ rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 5 1 0 1
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "9999999980",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 2,
|
||||
"Sequence": 3
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
|
||||
"PreviousFields": {
|
||||
"Balance": "9999999990",
|
||||
"OwnerCount": 1,
|
||||
"Sequence": 2
|
||||
},
|
||||
"PreviousTxnID": "389720F6FD8A144F171708F9ECB334D704CBCFEFBCDA152D931AC34FB5F9E32B",
|
||||
"PreviousTxnLgrSeq": 95405
|
||||
}
|
||||
},
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "718C6D58DD3BBAAAEBFE48B8FBE3C32C9F6F2EBC395233BA95D0057078EE07DB",
|
||||
"NewFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"Balance": "3732290013101",
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "100"
|
||||
},
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"value": "0"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Flags": 0,
|
||||
"Owner": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"RootIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"Balance": "78991384535796",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 3,
|
||||
"Sequence": 188
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 702820
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "B33FDD5CF3445E1A7F2BE9B06336BEBD73A5E3EE885D3EF93F7E3E2992E46F1A",
|
||||
"PreviousTxnID": "E9E1988A0F061679E5D14DE77DB0163CE0BBDC00F29E396FFD1DA0366E7D8904",
|
||||
"PreviousTxnLgrSeq": 195455
|
||||
"LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
|
||||
"PreviousFields": {
|
||||
"Balance": "3732745656171",
|
||||
"Sequence": 702819
|
||||
},
|
||||
"PreviousTxnID": "7C031FD5B710E3C048EEF31254089BEEC505900BCC9A842257A0319453333998",
|
||||
"PreviousTxnLgrSeq": 57112010
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"ExchangeRate": "4E11C37937E08000",
|
||||
"Account": "raLPjTYeGezfdb6crXZzcC8RkLBEwbBHJ5",
|
||||
"Balance": "4231510602153",
|
||||
"Flags": 0,
|
||||
"RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
|
||||
"TakerGetsCurrency": "0000000000000000000000000000000000000000",
|
||||
"TakerGetsIssuer": "0000000000000000000000000000000000000000",
|
||||
"TakerPaysCurrency": "0000000000000000000000004254430000000000",
|
||||
"TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 96486
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "39DC5D448DECEFC3CD20818788E3DA891CA943935E8D7B12FCB5B5871FCB1638",
|
||||
"PreviousFields": {
|
||||
"Balance": "4231054959123"
|
||||
},
|
||||
"PreviousTxnID": "33D2014C832610293730028CA37857AC183BFCE3E42B9979C491FB8B82B3E9DC",
|
||||
"PreviousTxnLgrSeq": 57112004
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 0,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
"TransactionIndex": 12,
|
||||
"TransactionResult": "tesSUCCESS",
|
||||
"delivered_amount": "455643030"
|
||||
},
|
||||
"tx": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Fee": "10",
|
||||
"Flags": 0,
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"value": "100"
|
||||
},
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
|
||||
"TransactionType": "TrustSet",
|
||||
"TxnSignature": "304402200EF81EC32E0DFA9BE376B20AFCA11765ED9FEA04CA8B77C7178DAA699F7F5AFF02202DA484DBD66521AC317D84F7717EC4614E2F5DB743E313E8B48440499CC0DBA4",
|
||||
"date": 413620090,
|
||||
"hash": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
|
||||
"inLedger": 195480,
|
||||
"ledger_index": 195480
|
||||
"Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"Amount": "455643030",
|
||||
"Destination": "raLPjTYeGezfdb6crXZzcC8RkLBEwbBHJ5",
|
||||
"DestinationTag": 18240312,
|
||||
"Fee": "40",
|
||||
"Flags": 2147483648,
|
||||
"LastLedgerSequence": 57112037,
|
||||
"Sequence": 702819,
|
||||
"SigningPubKey": "020A46D8D02AC780C59853ACA309EAA92E7D8E02DD72A0B6AC315A7D18A6C3276A",
|
||||
"TransactionType": "Payment",
|
||||
"TxnSignature": "30450221008602B2E390C0C7B65182C6DBC86292052C1961B2BEFB79C2C8431722C0ADB911022024B74DCF910A4C8C95572CF662EB7F5FF67E1AC4D7B9B7BFE2A8EE851EC16576",
|
||||
"date": 649200322,
|
||||
"hash": "08EF5BDA2825D7A28099219621CDBECCDECB828FEA202DEB6C7ACD5222D36C2C",
|
||||
"inLedger": 57112015,
|
||||
"ledger_index": 57112015
|
||||
},
|
||||
"validated": true
|
||||
},
|
||||
@@ -222,102 +329,61 @@ rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 5 1 0 1
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "9999999970",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 3,
|
||||
"Sequence": 4
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
|
||||
"PreviousFields": {
|
||||
"Balance": "9999999980",
|
||||
"OwnerCount": 2,
|
||||
"Sequence": 3
|
||||
},
|
||||
"PreviousTxnID": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
|
||||
"PreviousTxnLgrSeq": 195480
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Flags": 0,
|
||||
"Owner": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
|
||||
"RootIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "E0D7BDE68B468FF0B8D948FD865576517DA987569833A05374ADB9A72E870A06",
|
||||
"PreviousTxnID": "0222B59280D165D40C464EA75AAD08A4D152C46A38C0625DEECF6EE87FC5B9E1",
|
||||
"PreviousTxnLgrSeq": 343555
|
||||
}
|
||||
},
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "EA4BF03B4700123CDFFB6EB09DC1D6E28D5CEB7F680FB00FC24BC1C3BB2DB959",
|
||||
"NewFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"Balance": "3732745656171",
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "100"
|
||||
},
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
|
||||
"value": "0"
|
||||
}
|
||||
}
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 702819
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
|
||||
"PreviousFields": {
|
||||
"Balance": "3732246155784"
|
||||
},
|
||||
"PreviousTxnID": "CCBCCB528F602007C937C496F0828C118E073DF180084CCD3646EC1E414844E4",
|
||||
"PreviousTxnLgrSeq": 57112007
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"ExchangeRate": "4E11C37937E08000",
|
||||
"Flags": 0,
|
||||
"RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
|
||||
"TakerGetsCurrency": "0000000000000000000000000000000000000000",
|
||||
"TakerGetsIssuer": "0000000000000000000000000000000000000000",
|
||||
"TakerPaysCurrency": "0000000000000000000000004254430000000000",
|
||||
"TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
|
||||
"Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
|
||||
"Balance": "236476361",
|
||||
"Flags": 131072,
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 466335
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9",
|
||||
"PreviousFields": {
|
||||
"Balance": "735976788",
|
||||
"Sequence": 466334
|
||||
},
|
||||
"PreviousTxnID": "C528B32DD588EFAE2FE833E8AA92E6AE2DF2C8DB3DB8C6C4F334AD37B253D72A",
|
||||
"PreviousTxnLgrSeq": 57112010
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 0,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
"TransactionIndex": 33,
|
||||
"TransactionResult": "tesSUCCESS",
|
||||
"delivered_amount": "499500387"
|
||||
},
|
||||
"tx": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Fee": "10",
|
||||
"Flags": 0,
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
|
||||
"value": "100"
|
||||
},
|
||||
"Sequence": 3,
|
||||
"SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
|
||||
"TransactionType": "TrustSet",
|
||||
"TxnSignature": "3044022058A89552068D1A274EE72BA71363E33E54E6608BC28A84DEC6EE530FC2B5C979022029F4D1EA1237A1F717C5F5EC526E6CFB6DF54C30BADD25EDDE7D2FDBC8F17E34",
|
||||
"date": 416347560,
|
||||
"hash": "53354D84BAE8FDFC3F4DA879D984D24B929E7FEB9100D2AD9EFCD2E126BCCDC8",
|
||||
"inLedger": 343570,
|
||||
"ledger_index": 343570
|
||||
"Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
|
||||
"Amount": "499500387",
|
||||
"Destination": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"DestinationTag": 1,
|
||||
"Fee": "40",
|
||||
"Flags": 2147483648,
|
||||
"LastLedgerSequence": 57112032,
|
||||
"Sequence": 466334,
|
||||
"SigningPubKey": "0381575032E254BF4D699C3D8D6EFDB63B3A71F97475C6F6885BC7DAEEE55D9A01",
|
||||
"TransactionType": "Payment",
|
||||
"TxnSignature": "3045022100C7EA1701FE48C75508EEBADBC9864CD3FFEDCEB48AB99AEA960BFA360AE163ED0220453C9577502924C9E1A9A450D4B950A44016813BC70E1F16A65A402528D730B7",
|
||||
"date": 649200302,
|
||||
"hash": "7C031FD5B710E3C048EEF31254089BEEC505900BCC9A842257A0319453333998",
|
||||
"inLedger": 57112010,
|
||||
"ledger_index": 57112010
|
||||
},
|
||||
"validated": true
|
||||
}
|
||||
@@ -328,237 +394,35 @@ rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 5 1 0 1
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
{% tab label="コマンドライン" %}
|
||||
```json
|
||||
200 OK
|
||||
{
|
||||
"result": {
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"ledger_index_max": 8696227,
|
||||
"ledger_index_min": 32570,
|
||||
"limit": 2,
|
||||
"status": "success",
|
||||
"transactions": [
|
||||
{
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "9999999980",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 2,
|
||||
"Sequence": 3
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
|
||||
"PreviousFields": {
|
||||
"Balance": "9999999990",
|
||||
"OwnerCount": 1,
|
||||
"Sequence": 2
|
||||
},
|
||||
"PreviousTxnID": "389720F6FD8A144F171708F9ECB334D704CBCFEFBCDA152D931AC34FB5F9E32B",
|
||||
"PreviousTxnLgrSeq": 95405
|
||||
}
|
||||
},
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "718C6D58DD3BBAAAEBFE48B8FBE3C32C9F6F2EBC395233BA95D0057078EE07DB",
|
||||
"NewFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "100"
|
||||
},
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"value": "0"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Flags": 0,
|
||||
"Owner": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"RootIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"Balance": "78991384535796",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 3,
|
||||
"Sequence": 188
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "B33FDD5CF3445E1A7F2BE9B06336BEBD73A5E3EE885D3EF93F7E3E2992E46F1A",
|
||||
"PreviousTxnID": "E9E1988A0F061679E5D14DE77DB0163CE0BBDC00F29E396FFD1DA0366E7D8904",
|
||||
"PreviousTxnLgrSeq": 195455
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"ExchangeRate": "4E11C37937E08000",
|
||||
"Flags": 0,
|
||||
"RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
|
||||
"TakerGetsCurrency": "0000000000000000000000000000000000000000",
|
||||
"TakerGetsIssuer": "0000000000000000000000000000000000000000",
|
||||
"TakerPaysCurrency": "0000000000000000000000004254430000000000",
|
||||
"TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 0,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"tx": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Fee": "10",
|
||||
"Flags": 0,
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"value": "100"
|
||||
},
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
|
||||
"TransactionType": "TrustSet",
|
||||
"TxnSignature": "304402200EF81EC32E0DFA9BE376B20AFCA11765ED9FEA04CA8B77C7178DAA699F7F5AFF02202DA484DBD66521AC317D84F7717EC4614E2F5DB743E313E8B48440499CC0DBA4",
|
||||
"date": 413620090,
|
||||
"hash": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
|
||||
"inLedger": 195480,
|
||||
"ledger_index": 195480
|
||||
},
|
||||
"validated": true
|
||||
},
|
||||
{
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "9999999970",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 3,
|
||||
"Sequence": 4
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
|
||||
"PreviousFields": {
|
||||
"Balance": "9999999980",
|
||||
"OwnerCount": 2,
|
||||
"Sequence": 3
|
||||
},
|
||||
"PreviousTxnID": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
|
||||
"PreviousTxnLgrSeq": 195480
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Flags": 0,
|
||||
"Owner": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
|
||||
"RootIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "E0D7BDE68B468FF0B8D948FD865576517DA987569833A05374ADB9A72E870A06",
|
||||
"PreviousTxnID": "0222B59280D165D40C464EA75AAD08A4D152C46A38C0625DEECF6EE87FC5B9E1",
|
||||
"PreviousTxnLgrSeq": 343555
|
||||
}
|
||||
},
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "EA4BF03B4700123CDFFB6EB09DC1D6E28D5CEB7F680FB00FC24BC1C3BB2DB959",
|
||||
"NewFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "100"
|
||||
},
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
|
||||
"value": "0"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"ExchangeRate": "4E11C37937E08000",
|
||||
"Flags": 0,
|
||||
"RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
|
||||
"TakerGetsCurrency": "0000000000000000000000000000000000000000",
|
||||
"TakerGetsIssuer": "0000000000000000000000000000000000000000",
|
||||
"TakerPaysCurrency": "0000000000000000000000004254430000000000",
|
||||
"TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 0,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"tx": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Fee": "10",
|
||||
"Flags": 0,
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
|
||||
"value": "100"
|
||||
},
|
||||
"Sequence": 3,
|
||||
"SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
|
||||
"TransactionType": "TrustSet",
|
||||
"TxnSignature": "3044022058A89552068D1A274EE72BA71363E33E54E6608BC28A84DEC6EE530FC2B5C979022029F4D1EA1237A1F717C5F5EC526E6CFB6DF54C30BADD25EDDE7D2FDBC8F17E34",
|
||||
"date": 416347560,
|
||||
"hash": "53354D84BAE8FDFC3F4DA879D984D24B929E7FEB9100D2AD9EFCD2E126BCCDC8",
|
||||
"inLedger": 343570,
|
||||
"ledger_index": 343570
|
||||
},
|
||||
"validated": true
|
||||
}
|
||||
],
|
||||
"validated": true
|
||||
}
|
||||
"result" : {
|
||||
"account" : "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
|
||||
"ledger_index_max" : 57112094,
|
||||
"ledger_index_min" : 57105464,
|
||||
"limit" : 2,
|
||||
"marker" : {
|
||||
"ledger" : 57112074,
|
||||
"seq" : 9
|
||||
},
|
||||
"status" : "success",
|
||||
"transactions" : [
|
||||
{
|
||||
"ledger_index" : 57112090,
|
||||
"meta" : "201C0000002EF8E51100612503677617551E0297F38EF4FED7004E074D246B4EA3E550D9AE0F61BE40E08D3432091D52CE56140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574E624000AB96E624000037771BFD270E1E7220002000024000AB96F2D0000000062400003776C784A418114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911E1E1E311006156F7D315E0E992B1F1AC66B309C9D68961AA327FE770101B74D4C975F8C5DEC96AE8240367761A624000000005478807811403C95DC0C7CE402E8044A5F13304108013CE9963E1E1F1031000",
|
||||
"tx_blob" : "120000228000000024000AB96E201B036776306140000000054788076840000000000000287321020A46D8D02AC780C59853ACA309EAA92E7D8E02DD72A0B6AC315A7D18A6C3276A74463044022054811EEF61ACCFA1B5FC6BB05D2FA49CF5174062740370328382E6EA557C0E6A0220480584D487638C333A87CA37100354BD36209E355E8DB9FE79791A56E24C1F268114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911831403C95DC0C7CE402E8044A5F13304108013CE9963",
|
||||
"validated" : true
|
||||
},
|
||||
{
|
||||
"ledger_index" : 57112087,
|
||||
"meta" : "201C00000026F8E5110061250367760A556B80EE9A9AD3FC40F471F29DCB80C678375137CE36220718902EF1EDCD375E7156140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574E66240000376DEB77118E1E7220002000024000AB96E2D00000000624000037771BFD2708114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911E1E1E511006125036776155591DA498D40AFD90670555F3D719883B48D224B4E4E906C634DEFA21163E8197756CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9E62400071DA26240000001C0D849F8E1E722000200002400071DA32D0000000062400000012DCFE87881146914CB622B8E41E150DE431F48DA244A69809366E1E1F1031000",
|
||||
"tx_blob" : "12000022800000002400071DA22E00000001201B0367762D61400000009308615868400000000000002873210381575032E254BF4D699C3D8D6EFDB63B3A71F97475C6F6885BC7DAEEE55D9A0174473045022100E592BCCFD85CCE0B39075EFC66D6BCA594EBB451F12AD5AD9EE533A267F1381B02203635AB46AC110848FC44E797BD19D77A19E10A0F463AA5540B1C62E5D48C81F081146914CB622B8E41E150DE431F48DA244A698093668314D2E44C9FAF7BE9C536219800A6E698E4C7D2C911",
|
||||
"validated" : true
|
||||
}
|
||||
],
|
||||
"validated" : true
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
@@ -62,7 +62,7 @@ rippled ledger current
|
||||
|
||||
| `Field` | 型 | 必須? | 説明 |
|
||||
|:---------------|:---------------------|:------|:-------------------------------|
|
||||
| `ledger_hash` | [ハッシュ][] | いいえ | 使用するレジャーバージョンの20バイトの16進文字列。([レジャーの指定][]ご覧ください。) |
|
||||
| `ledger_hash` | [ハッシュ][] | いいえ | 使用するレジャーバージョンの32バイトの16進文字列。([レジャーの指定][]ご覧ください。) |
|
||||
| `ledger_index` | [レジャーインデックス][] | いいえ | 使用するレジャーの[レジャーインデックス][]、またはレジャーを自動的に選択するためのショートカット文字列。([レジャーの指定][]をご覧ください) |
|
||||
| `transactions` | 真偽値 | いいえ | `true`の場合、指定されたレジャーバージョンのトランザクションに関する情報が返されます。デフォルトでは`false`です。レジャーバージョンを指定しない場合は無視されます。 |
|
||||
| `expand` | 真偽値 | いいえ | ハッシュのみではなく、トランザクション/アカウントの完全な情報がJSONフォーマットで提供されます。デフォルトでは`false`です。トランザクション、アカウント、またはその両方をリクエストしない場合は無視されます。 |
|
||||
|
||||
@@ -30,18 +30,24 @@ label:
|
||||
|
||||
上記の一般的なフィールドに加えて、オブジェクトを取得するタイプを示すために、以下のフィールドのうち *正確に1つ* を指定する必要があります。有効なフィールドは以下のとおりです。
|
||||
|
||||
- [`index`](#idからレジャーオブジェクトを取得する)
|
||||
- [`account_root`](#accountrootオブジェクトを取得する)
|
||||
- [`directory`](#directorynodeオブジェクトを取得する)
|
||||
- [`amm`](#ammオブジェクトを取得する)
|
||||
- [`offer`](#offerオブジェクトを取得する)
|
||||
- [`ripple_state`](#ripplestateオブジェクトを取得する)
|
||||
- [`check`](#checkオブジェクトを取得する)
|
||||
- [`escrow`](#escrowオブジェクトを取得する)
|
||||
- [`payment_channel`](#paychannelオブジェクトを取得する)
|
||||
- [`deposit_preauth`](#depositpreauthオブジェクトを取得する)
|
||||
- [`ticket`](#ticketオブジェクトを取得する)
|
||||
- [`nft_page`](#nft-pageを取得する)
|
||||
- [ledger\_entry](#ledger_entry)
|
||||
- [リクエストのフォーマット](#リクエストのフォーマット)
|
||||
- [一般的なフィールド](#一般的なフィールド)
|
||||
- [IDからレジャーオブジェクトを取得する](#idからレジャーオブジェクトを取得する)
|
||||
- [AccountRootオブジェクトを取得する](#accountrootオブジェクトを取得する)
|
||||
- [AMMオブジェクトを取得する](#ammオブジェクトを取得する)
|
||||
- [Bridgeオブジェクトを取得する](#bridgeオブジェクトを取得する)
|
||||
- [Directorynodeオブジェクトを取得する](#directorynodeオブジェクトを取得する)
|
||||
- [Offerオブジェクトを取得する](#offerオブジェクトを取得する)
|
||||
- [RippleStateオブジェクトを取得する](#ripplestateオブジェクトを取得する)
|
||||
- [Checkオブジェクトを取得する](#checkオブジェクトを取得する)
|
||||
- [Escrowオブジェクトを取得する](#escrowオブジェクトを取得する)
|
||||
- [Paychannelオブジェクトを取得する](#paychannelオブジェクトを取得する)
|
||||
- [DepositPreauthオブジェクトを取得する](#depositpreauthオブジェクトを取得する)
|
||||
- [Ticketオブジェクトを取得する](#ticketオブジェクトを取得する)
|
||||
- [Nft Pageを取得する](#nft-pageを取得する)
|
||||
- [レスポンスのフォーマット](#レスポンスのフォーマット)
|
||||
- [考えられるエラー](#考えられるエラー)
|
||||
|
||||
**注意:** リクエストでこれらの型固有のフィールドを1つ以上指定した場合、サーバはそのうちの1つだけの結果を取得します。サーバがどれを選択するかは定義されていないため、こうした指定方法は避けるべきです。
|
||||
|
||||
@@ -95,7 +101,7 @@ rippled json ledger_entry '{ "index": "7DB0788C020F02780A673DC74757F23823FA3014C
|
||||
|
||||
- [`Amendments`](../../../protocol/ledger-data/ledger-entry-types/amendments.md) - `7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4`
|
||||
- [`FeeSettings`](../../../protocol/ledger-data/ledger-entry-types/feesettings.md) - `4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651`
|
||||
- [Recent History `LedgerHashes`](../../../protocol/ledger-data/ledger-entry-types/ledgerhashes.md) - `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`
|
||||
- [直近の`LedgerHashes`](../../../protocol/ledger-data/ledger-entry-types/ledgerhashes.md) - `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`
|
||||
- [`NegativeUNL`](../../../protocol/ledger-data/ledger-entry-types/negativeunl.md) - `2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244`
|
||||
{% /admonition %}
|
||||
|
||||
@@ -175,7 +181,7 @@ _([AMM amendment][])_
|
||||
"currency" : "TST",
|
||||
"issuer" : "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
|
||||
}
|
||||
}
|
||||
},
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
```
|
||||
@@ -211,7 +217,77 @@ rippled json ledger_entry '{ "amm": { "asset": { "currency": "XRP" }, "asset2":
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
[試してみる >](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Famm.devnet.rippletest.net%3A51233%2F#ledger_entry-amm)
|
||||
[試してみる >](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs.devnet.rippletest.net%3A51233%2F#ledger_entry-amm)
|
||||
|
||||
|
||||
### Bridgeオブジェクトを取得する
|
||||
|
||||
_([XChainBridge amendment][]が必要です {% not-enabled /%})_
|
||||
|
||||
XRP Ledgerを他のブロックチェーンに接続する1つのクロスチェーンブリッジを表す[Bridgeエントリ](../../../protocol/ledger-data/ledger-entry-types/bridge.md)を取得します。
|
||||
|
||||
| フィールド | 型 | 説明 |
|
||||
|:-----------------|:-----------|:----------------------|
|
||||
| `bridge_account` | 文字列 | ブロックチェーン上で`XChainCreateBridge`トランザクションを送信したアカウント。 |
|
||||
| `bridge` | オブジェクト | 取得する[ブリッジ](../../../protocol/ledger-data/ledger-entry-types/bridge.md)。ドアアカウントと発行・ロックチェーンの資産の情報を含みます。 |
|
||||
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": "example_get_bridge",
|
||||
"command": "ledger_entry",
|
||||
"bridge_account": "rnQAXXWoFNN6PEqwqsdTngCtFPCrmfuqFJ",
|
||||
"bridge": {
|
||||
"IssuingChainDoor": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"IssuingChainIssue": {
|
||||
"currency": "XRP"
|
||||
},
|
||||
"LockingChainDoor": "rnQAXXWoFNN6PEqwqsdTngCtFPCrmfuqFJ",
|
||||
"LockingChainIssue": {
|
||||
"currency": "XRP"
|
||||
}
|
||||
},
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"method": "ledger_entry",
|
||||
"params": [
|
||||
{
|
||||
"bridge_account": "rnQAXXWoFNN6PEqwqsdTngCtFPCrmfuqFJ",
|
||||
"bridge": {
|
||||
"IssuingChainDoor": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"IssuingChainIssue": {
|
||||
"currency": "XRP"
|
||||
},
|
||||
"LockingChainDoor": "rnQAXXWoFNN6PEqwqsdTngCtFPCrmfuqFJ",
|
||||
"LockingChainIssue": {
|
||||
"currency": "XRP"
|
||||
}
|
||||
},
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```sh
|
||||
rippled json ledger_entry '{ "bridge_account": "rnQAXXWoFNN6PEqwqsdTngCtFPCrmfuqFJ", "bridge": { "IssuingChainDoor": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "IssuingChainIssue": { "currency": "XRP" }, "LockingChainDoor": "rnQAXXWoFNN6PEqwqsdTngCtFPCrmfuqFJ", "LockingChainIssue": { "currency": "XRP" } }, "ledger_index": "validated" }'
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
[試してみよう! >](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs.devnet.rippletest.net%3A51233%2F#ledger_entry-bridge)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -63,12 +63,12 @@ _([AMM amendment][])_
|
||||
|
||||
リクエストには以下のパラメーターが含まれます。
|
||||
|
||||
| `フィールド` | 型 | 必須? | 説明 |
|
||||
|:--------------|:-----------------------|:------|:-----------------------------------|
|
||||
| `account` | 文字列 - [アドレス][] | いいえ | この流動性プロバイダーが保有するLPトークンのみを表示します。 |
|
||||
| `amm_account` | 文字列 - [アドレス][] | いいえ | AMMの特別なAccountRootのアドレス。(これはAMMのLPトークンの`issuer`です)。 |
|
||||
| `asset` | オブジェクト または 文字列 | いいえ | [通貨額][Currency Amount]のように、`currency`と`issuer`フィールドを持つオブジェクトとして（XRPの場合は`issuer`を省略）、検索するAMMの資産の一つを指定します。XRPの場合は、オブジェクトではなく文字列`XRP`として指定することもできます。 |
|
||||
| `asset2` | オブジェクト または 文字列 | いいえ | AMMの資産のもう一方を、`currency`と`issuer`フィールド（XRPの場合は`issuer`を省略）を持つオブジェクトとして、[通貨額][Currency Amount]のように指定することが可能です。 |
|
||||
| `フィールド` | 型 | 必須? | 説明 |
|
||||
|:--------------|:--------------------|:------|:-----------------------------------|
|
||||
| `account` | 文字列 - [アドレス][] | いいえ | この流動性プロバイダーが保有するLPトークンのみを表示します。 |
|
||||
| `amm_account` | 文字列 - [アドレス][] | いいえ | AMMの特別なAccountRootのアドレス。(これはAMMのLPトークンの`issuer`です)。 |
|
||||
| `asset` | オブジェクト | いいえ | [通貨額][Currency Amount]のように、`currency`と`issuer`フィールドを持つオブジェクトとして（XRPの場合は`issuer`を省略）、検索するAMMの資産の一つを指定します。 |
|
||||
| `asset2` | オブジェクト | いいえ | AMMの資産のもう一方を、`currency`と`issuer`フィールド（XRPの場合は`issuer`を省略）を持つオブジェクトとして、[通貨額][Currency Amount]のように指定することが可能です。 |
|
||||
|
||||
`amm_account`、または`asset`と`asset2`の両方を指定する必要があります。
|
||||
|
||||
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
html: server_definitions.html
|
||||
parent: server-info-methods.html
|
||||
seo:
|
||||
description: 実行中の`rippled`インスタンスから生成されるSDK互換の`definitions.json`を取得します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# server_definitions
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/ServerInfo.cpp#L43 "ソース")
|
||||
|
||||
`server_definitions`コマンドは実行中の`rippled`インスタンスから生成されたSDK互換の`definitions.json`を返します。これを使用してネットワーク上のノードにアクセスし、そのバイナリデータをシリアライズ/デシリアライズするために必要な定義を受け取ることができます。
|
||||
|
||||
|
||||
## リクエストのフォーマット
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
"command": "server_definitions"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"method": "server_definitions"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
[試してみよう! >](/resources/dev-tools/websocket-api-tool#server_definitions)
|
||||
|
||||
リクエストにパラメータは含まれません。
|
||||
|
||||
|
||||
## レスポンスのフォーマット
|
||||
|
||||
レスポンスのフォーマットの例:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 1,
|
||||
"result": {
|
||||
"FIELDS": [
|
||||
[
|
||||
"Generic",
|
||||
{
|
||||
"isSerialized": false,
|
||||
"isSigningField": false,
|
||||
"isVLEncoded": false,
|
||||
"nth": 0,
|
||||
"type": "Unknown"
|
||||
}
|
||||
],
|
||||
[
|
||||
"Invalid",
|
||||
{
|
||||
"isSerialized": false,
|
||||
"isSigningField": false,
|
||||
"isVLEncoded": false,
|
||||
"nth": -1,
|
||||
"type": "Unknown"
|
||||
}
|
||||
],
|
||||
[
|
||||
"ObjectEndMarker",
|
||||
{
|
||||
"isSerialized": true,
|
||||
"isSigningField": true,
|
||||
"isVLEncoded": false,
|
||||
"nth": 1,
|
||||
"type": "STObject"
|
||||
}
|
||||
],
|
||||
[
|
||||
"ArrayEndMarker",
|
||||
{
|
||||
"isSerialized": true,
|
||||
"isSigningField": true,
|
||||
"isVLEncoded": false,
|
||||
"nth": 1,
|
||||
"type": "STArray"
|
||||
}
|
||||
]
|
||||
...
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
完全な`definitions.json`ファイルとトップレベルフィールドの説明を見るには、[定義ファイル](../../../protocol/binary-format.md#定義ファイル)をご覧ください。
|
||||
|
||||
|
||||
## 考えられるエラー
|
||||
|
||||
いずれかの汎用エラータイプ。
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -12,6 +12,8 @@ labels:
|
||||
|
||||
`server_state`コマンドは、サーバに対し`rippled`サーバの現在の状態に関するさまざまな機械可読の情報を問い合わせます。レスポンスは[server_infoメソッド][]の場合とほぼ同じですが、読み取りやすい単位ではなく処理しやすい単位を使用します。（たとえば、XRP値は科学的記数法や10進数値の代わりに整数のdrop数で示され、時刻は秒単位ではなくミリ秒単位で示されます。）
|
||||
|
||||
The [Clio server](../../../../concepts/networks-and-servers/the-clio-server.md) does not support `server_state` directly, but you can ask for the `server_state` of the `rippled` server that Clio is connected to. Specify `"ledger_index": "current"` (WebSocket) or `"params": [{"ledger_index": "current"}]` (JSON-RPC).
|
||||
|
||||
## リクエストのフォーマット
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
@@ -20,8 +22,9 @@ labels:
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
"command": "server_state"
|
||||
"id": 2,
|
||||
"command": "server_state",
|
||||
"ledger_index": "current"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
@@ -29,10 +32,10 @@ labels:
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"method": "server_state",
|
||||
"params": [
|
||||
{}
|
||||
]
|
||||
"method": "server_state",
|
||||
"params": [
|
||||
{"ledger_index": "current"}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
@@ -313,6 +316,8 @@ Headers
|
||||
| `validation_quorum` | 数値 | 1つのレジャーバージョンの検証に最低限必要となる信頼できる検証の数。状況によっては、サーバがさらに検証をリクエストする場合があります。 |
|
||||
| `validator_list_expires` | 数値 | _（管理者専用）_ 現在のバリデータリストが期限切れになる時点（[Rippleエポック以降の経過秒数][]）。サーバが発行済みのバリデータリストをロードしていない場合は0。 |
|
||||
|
||||
[レポートモード]: ../../../../concepts/networks-and-servers/rippled-server-modes.md
|
||||
|
||||
{% partial file="/@i18n/ja/docs/_snippets/etl-source-object.md" /%}
|
||||
|
||||
{% partial file="/@i18n/ja/docs/_snippets/port-descriptor-object.md" /%}
|
||||
|
||||
61
@i18n/ja/docs/references/index.md
Normal file
61
@i18n/ja/docs/references/index.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
seo:
|
||||
description: XRP LedgerプロトコルやAPIメソッドなどのリファレンスドキュメント
|
||||
---
|
||||
# リファレンス
|
||||
|
||||
XRP LedgerリファレンスはXRP LedgerプロトコルやAPIメソッドなどのドキュメントです。
|
||||
|
||||
## クライアントライブラリ
|
||||
|
||||
お使いのプログラミング言語からXRP Ledgerにアクセスするには、以下のライブラリをご利用ください。
|
||||
|
||||
{% card-grid %}
|
||||
|
||||
{% xrpl-card title="JavaScript / TypeScript" body="xrpl.js - JavaScript/TypeScriptライブラリ" href="https://js.xrpl.org/" image="/img/logos/javascript.svg" imageAlt="Javascript logo" /%}
|
||||
|
||||
{% xrpl-card title="Python" body="xrpl.py - Pythonライブラリ" href="https://xrpl-py.readthedocs.io/" image="/img/logos/python.svg" imageAlt="Python logo" /%}
|
||||
|
||||
{% xrpl-card title="Java" body="xrpl4j - Javaライブラリ" href="https://javadoc.io/doc/org.xrpl/" image="/img/logos/java.svg" imageAlt="Java logo" /%}
|
||||
|
||||
{% /card-grid %}
|
||||
|
||||
[さらに見る...](/ja/docs/references/client-libraries/)
|
||||
|
||||
## XRP Ledgerプロトコルリファレンス
|
||||
|
||||
{% card-grid %}
|
||||
|
||||
{% xrpl-card title="基本的なデータ" body="基本的なデータの形式と定義" href="/docs/references/protocol/data-types/basic-data-types/" /%}
|
||||
|
||||
{% xrpl-card title="レジャーのデータ" body="XRP Ledgerの状態データを構成する個々のデータ" href="/docs/references/protocol/ledger-data/" /%}
|
||||
|
||||
{% xrpl-card title="トランザクション" body="プロトコルのすべてのトランザクションタイプとその結果の定義" href="/docs/references/protocol/transactions/" /%}
|
||||
|
||||
{% xrpl-card title="バイナリフォーマット" body="XRP Ledgerのトランザクションやその他のオブジェクトのJSON形式と標準バイナリデータとの変換" href="/docs/references/protocol/binary-format/" /%}
|
||||
|
||||
{% /card-grid %}
|
||||
|
||||
## HTTP / WebSocket API
|
||||
|
||||
{% card-grid %}
|
||||
|
||||
{% xrpl-card title="APIの規約" body="rippledサーバに実装されているHTTP API(JSON-RPCとWebSocket)のデータタイプとフォーマットの説明" href="/docs/references/http-websocket-apis/api-conventions/" /%}
|
||||
|
||||
{% xrpl-card title="公開APIメソッド" body="サーバーに接続されたクライアントが使用する公開APIメソッド" href="/docs/references/http-websocket-apis/public-api-methods/" /%}
|
||||
|
||||
{% xrpl-card title="管理者APIメソッド" body="rippledサーバを運用する信頼できる管理者のための管理者APIメソッド" href="/docs/references/http-websocket-apis/admin-api-methods/" /%}
|
||||
|
||||
{% xrpl-card title="Peer Portメソッド" body="XRPL Peer Protocolポートで提供される、ネットワーク情報とステータス情報を共有するための特別なAPIメソッド" href="/docs/references/http-websocket-apis/peer-port-methods/" /%}
|
||||
|
||||
{% /card-grid %}
|
||||
|
||||
## xrp-ledger.tomlファイル
|
||||
|
||||
xrp-ledger.tomlファイルは、他のXRP Ledgerユーザに、あなたのXRP Ledgerの使用状況に関する可読情報を提供します。
|
||||
|
||||
- [**ファイルの提供方法**](/ja/docs/references/xrp-ledger-toml/#ファイルの提供方法)
|
||||
- [**内容**](/ja/docs/references/xrp-ledger-toml/#内容)
|
||||
- [**CORSの設定**](/ja/docs/references/xrp-ledger-toml/#corsの設定)
|
||||
- [**ドメイン検証**](/ja/docs/references/xrp-ledger-toml/#ドメイン検証)
|
||||
- [**アカウント検証**](/ja/docs/references/xrp-ledger-toml/#アカウント検証)
|
||||
@@ -39,7 +39,7 @@ C) 160ビットの発行者のアカウント識別子
|
||||
|
||||
D) 32ビットの発行者が指定する[`NFTokenTaxon`](https://www.merriam-webster.com/dictionary/taxon)
|
||||
|
||||
E) 32ビットの（自動生成される）単調増加するのシーケンス番号
|
||||
E) 32ビットの（自動生成される）単調増加するシーケンス番号
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,21 +1,20 @@
|
||||
---
|
||||
html: directorynode.html
|
||||
parent: ledger-entry-types.html
|
||||
seo:
|
||||
description: 他のオブジェクトへのリンクを含みます。
|
||||
description: 他のオブジェクトへのリンクを保持します。
|
||||
labels:
|
||||
- 分散型取引所
|
||||
- データ保持
|
||||
- 分散型取引所
|
||||
---
|
||||
# DirectoryNode
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")
|
||||
|
||||
`DirectoryNode`オブジェクトタイプは、レジャーの状態ツリー内の他オブジェクトへのリンクのリストを提供します。概念上の1つの _ディレクトリ_ は、1つ以上の各DirectoryNodeオブジェクトが含まれる二重リンクリストの形式になっています。各DirectoryNodeオブジェクトには、他オブジェクトの[ID](../common-fields.md)が最大32個まで含まれています。1番目のオブジェクトはディレクトリのルートと呼ばれ、ルートオブジェクト以外のオブジェクトはすべて必要に応じて自由に追加または削除できます。
|
||||
|
||||
2種類のディレクトリがあります。
|
||||
ディレクトリには3種類があります。
|
||||
|
||||
* **所有者ディレクトリ**は、アカウントが所有するその他のオブジェクト（`RippleState`オブジェクトや`Offer`オブジェクトなど）をリストします。
|
||||
* **オファーディレクトリ**は、分散型取引所で利用可能なオファーをリストします。1つのオファーディレクトリには、同一イシュアンスに同一為替レートが設定されているすべてのオファーが含まれます。
|
||||
* _所有者ディレクトリ_ は、[`RippleState`(トラストライン)](ripplestate.md)エントリや[`Offer`](offer.md)エントリなどアカウントが所有するその他のエントリの一覧です。
|
||||
* _オファーディレクトリ_ は、[分散型取引所(DEX)](../../../../concepts/tokens/decentralized-exchange/index.md)で利用可能なオファーの一覧です。1つのオファーディレクトリには、同一トークン(通貨コードと発行者)に同一の取引レートが設定されているすべてのオファーが含まれます。
|
||||
* _NFTオファーディレクトリ_ は、NFTの買いオファーと売りオファーの一覧です。各NFTには、買いオファー用と売りオファー用の2つのディレクトリがあります。
|
||||
|
||||
## {% $frontmatter.seo.title %}のJSONの例
|
||||
|
||||
@@ -56,6 +55,29 @@ labels:
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="NFTオファーディレクトリ" %}
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"index": "CC45A27DAF06BFA45E8AFC92801AD06A06B7004DAD0F7022E439B3A2F6FA5B5A",
|
||||
"ledger_current_index": 310,
|
||||
"node": {
|
||||
"Flags": 2,
|
||||
"Indexes": [
|
||||
"83C81AC39F9771DDBCD66F6C225FC76EFC0971384EC6148BAFA5BD18019FC495"
|
||||
],
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"NFTokenID": "000800009988C43C563A7BB35AF34D642990CDF089F11B445EB3DCCD00000132",
|
||||
"RootIndex": "CC45A27DAF06BFA45E8AFC92801AD06A06B7004DAD0F7022E439B3A2F6FA5B5A",
|
||||
"index": "CC45A27DAF06BFA45E8AFC92801AD06A06B7004DAD0F7022E439B3A2F6FA5B5A"
|
||||
},
|
||||
"status": "success",
|
||||
"validated": false
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
## {% $frontmatter.seo.title %}のフィールド
|
||||
@@ -68,6 +90,7 @@ labels:
|
||||
| `IndexNext` | 数値 | UInt64 | いいえ | （省略可）このディレクトリに複数のページが含まれている場合、このIDはチェーン内の次のオブジェクトにリンクし、末尾でラップアラウンドします。 |
|
||||
| `IndexPrevious` | 数値 | UInt64 | いいえ | （省略可）このディレクトリに複数のページが含まれている場合、このIDはチェーン内の前のオブジェクトにリンクし、先頭でラップアラウンドします。 |
|
||||
| `LedgerEntryType` | 文字列 | UInt16 | はい | 値が`0x0064`（文字列`DirectoryNode`にマッピング）の場合は、このオブジェクトがディレクトリの一部であることを示します。 |
|
||||
| `NFTokenID` | 文字列 | Hash25 | No |(NFTオファーディレクトリのみ) 購入または売却オファーに紐づくNFTのID。. |
|
||||
| `Owner` | 文字列 | AccountID | いいえ | （所有者ディレクトリのみ）このディレクトリ内のオブジェクトを所有するアカウントのアドレス。 |
|
||||
| `RootIndex` | 文字列 | Hash256 | はい | このディレクトリのルートオブジェクトのID。 |
|
||||
| `TakerGetsCurrency` | 文字列 | Hash160 | いいえ | （オファーディレクトリのみ）このディレクトリのオファーのTakerGetsの額の通貨コード。 |
|
||||
@@ -90,11 +113,11 @@ labels:
|
||||
|
||||
DirectoryNodeのIDを作成するときには、DirectoryNodeが以下のどのページを表しているかに応じて3種類の方式があります。
|
||||
|
||||
* 所有者ディレクトリの1番目のページ（ルートとも呼ばれます）
|
||||
* 所有者ディレクトリまたはNFTオファーディレクトリの1番目のページ（ルートとも呼ばれます）
|
||||
* オファーディレクトリの1番目のページ
|
||||
* いずれかのディレクトリの以降のページ
|
||||
|
||||
**所有者ディレクトリの1番目のページ**のIDは、以下の値がこの順序で連結されている[SHA-512ハーフ][]です。
|
||||
**所有者ディレクトリまたはNFTオファーディレクトリの1番目のページ**のIDは、以下の値がこの順序で連結されている[SHA-512ハーフ][]です。
|
||||
|
||||
* 所有者ディレクトリのスペースキー（`0x004F`）
|
||||
* `Owner`フィールドのAccountID。
|
||||
@@ -109,7 +132,7 @@ DirectoryNodeのIDを作成するときには、DirectoryNodeが以下のどの
|
||||
|
||||
オファーディレクトリのIDの下位64ビットは、そのディレクトリ内のオファーのTakerPaysの額をTakerGetsの額で割った結果を、XRP Ledgerの内部金額フォーマットの64ビット数値で表したものです。
|
||||
|
||||
**DirectoryNodeがディレクトリの1番目のページではない場合**（所有者ディレクトリ、オファーディレクトリのいずれの場合でも）、DirectoryNodeのIDは、以下の値をこの順序で連結した[SHA-512ハーフ][]です。
|
||||
**DirectoryNodeがディレクトリの1番目のページではない場合**、DirectoryNodeのIDは、以下の値をこの順序で連結した[SHA-512ハーフ][]です。
|
||||
|
||||
* DirectoryNodeスペースキー（`0x0064`）
|
||||
* ルートDirectoryNodeのID
|
||||
|
||||
@@ -47,9 +47,9 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました)_
|
||||
| 名前 | JSONの型 | [内部の型][] | 必須？ | 説明 |
|
||||
|:--------------------|:----------|:-----------|:----------|:------------|
|
||||
| `LedgerEntryType` | 文字列 | UInt16 | はい | レジャーオブジェクトのタイプを識別文字列です。予約されているレジャーの種類は、0x0050です。|
|
||||
| `NextPageMin` | 文字列 | Hash256 | いいえ | 次のページの位置情報(もしあれば)。このフィールドの詳細および使用方法については、NFTokenPageID の構築についての説明以降に記載しています。|
|
||||
| `NextPageMin` | 文字列 | Hash256 | いいえ | 次のページの位置情報(もしあれば)。このフィールドの使用方法は、NFTokenオブジェクトの追加の項に記載しています。|
|
||||
| `NFTokens` | オブジェクト | TOKEN | はい | このNFTokenPageオブジェクトに含まれる`NFToken`オブジェクトのコレクション。本仕様では、1ページあたり32のNFTokenオブジェクトを上限としています。オブジェクトは、`NFTokenID`をソートパラメータとして使用して、低いものから高いものへとソートされた順序で格納されています。|
|
||||
| `PreviousPageMin` | 文字列 | Hash256 | いいえ | 前のページの位置情報(もしあれば)。このフィールドの詳細および使用方法については、NFTokenPageIDの構築についての説明以降に記載しています。|
|
||||
| `PreviousPageMin` | 文字列 | Hash256 | いいえ | 前のページの位置情報(もしあれば)。このフィールドの使用方法は、NFTokenオブジェクトの追加の項に記載しています。|
|
||||
| `PreviousTxnID` | 文字列 | HASH256 | いいえ | このNFTokenPageオブジェクトを最も最近変更したトランザクションのトランザクションIDの情報を示します。|
|
||||
| `PreviousTxnLgrSeq` | 数値 | UInt32 | いいえ | このNFTokenPageオブジェクトを最も最近変更したトランザクションを含むレジャーのシーケンスを示します。|
|
||||
|
||||
@@ -79,7 +79,7 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました)_
|
||||
|
||||
### `NFToken`オブジェクトの削除
|
||||
|
||||
`NFToken`は同じ手法で削除することもできます。ページ内の`NFToken`の数がある閾値を下回ると、サーバはそのページを前後のページと統合して準備金を取り戻そうとします。
|
||||
`NFToken`の削除も追加と同じように動作します。ページ内の`NFToken`の数がある閾値を下回ると、サーバはそのページを前後のページと統合して準備金を取り戻そうとします。
|
||||
|
||||
|
||||
### {% $frontmatter.seo.title %}の準備金
|
||||
|
||||
@@ -73,6 +73,7 @@ labels:
|
||||
|
||||
| フラグ名 | 16進数値 | 10進数値 | 対応する[TrustSetフラグ](../../transactions/types/trustset.md#trustsetのフラグ) | 説明 |
|
||||
|-------------------|--------------|----------|-------------|------------------------|
|
||||
| `lsfAMMNode` | `0x01000000` | 16777216 | (なし) | このトラストラインがAMMアカウントに紐づくことを表します。 |
|
||||
| `lsfLowReserve` | `0x00010000` | 65536 | （なし） | このRippleStateオブジェクトは[低位アカウント所有者の準備金に資金を供給します](#所有者の準備金への資金供給)。 |
|
||||
| `lsfHighReserve` | `0x00020000` | 131072 | （なし） | このRippleStateオブジェクトは[高位アカウント所有者の準備金に資金を供給します](#所有者の準備金への資金供給)。 |
|
||||
| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | 低位アカウントにより、高位アカウントが低位アカウントのイシュアンスを保有することが承認されています。 |
|
||||
|
||||
@@ -16,11 +16,184 @@ labels:
|
||||
|
||||
{% partial file="/@i18n/ja/docs/_snippets/tx-metadata-field-table.md" /%}
|
||||
|
||||
|
||||
## メタデータの例
|
||||
|
||||
次のJSONオブジェクトは、[複雑なクロスカレンシー支払い](https://livenet.xrpl.org/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B)のメタデータを示しています。
|
||||
次のJSONオブジェクトは、[XRPからUSDへの交換](https://livenet.xrpl.org/transactions/424661CF1FD3675D11EC910CF161979553B6D135F9BD03E6F8D4611D88D27581)のメタデータを示しています。
|
||||
|
||||
```json
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rBTwLga3i2gz3doX6Gva3MgEV8ZCD8jjah",
|
||||
"Balance": "27724423128",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 14,
|
||||
"Sequence": 129693478
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "1ED8DDFD80F275CB1CE7F18BB9D906655DE8029805D8B95FB9020B30425821EB",
|
||||
"PreviousFields": {
|
||||
"Balance": "27719423228",
|
||||
"Sequence": 129693477
|
||||
},
|
||||
"PreviousTxnID": "3110F983CDC090750B45C9BFB74B8CE629CA80F57C35612402B2760153822BA5",
|
||||
"PreviousTxnLgrSeq": 86724072
|
||||
}
|
||||
},
|
||||
{
|
||||
"DeletedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rPx6Rbh8fStXeP3LwECBisownN2ZyMyzYS",
|
||||
"BookDirectory": "DFA3B6DDAB58C7E8E5D944E736DA4B7046C30E4F460FD9DE4E1566CBCC208000",
|
||||
"BookNode": "0",
|
||||
"Flags": 0,
|
||||
"OwnerNode": "0",
|
||||
"PreviousTxnID": "DCB061EC44BBF73BBC20CE0432E9D8D7C4B8B28ABA8AE5A5BA687476E7A796EF",
|
||||
"PreviousTxnLgrSeq": 86724050,
|
||||
"Sequence": 86586865,
|
||||
"TakerGets": "0",
|
||||
"TakerPays": {
|
||||
"currency": "USD",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "0"
|
||||
}
|
||||
},
|
||||
"LedgerEntryType": "Offer",
|
||||
"LedgerIndex": "348AF66EBD872FBF2BD23085D3FB4A200E15509451475027C4A5EE8D8B77C623",
|
||||
"PreviousFields": {
|
||||
"TakerGets": "5000000",
|
||||
"TakerPays": {
|
||||
"currency": "USD",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "3.012"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Flags": 0,
|
||||
"Owner": "rPx6Rbh8fStXeP3LwECBisownN2ZyMyzYS",
|
||||
"RootIndex": "4A68E363398C8DA470CF85237CA4A044476CD38BA7D5C9B8E8F19417A13B01C1"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "4A68E363398C8DA470CF85237CA4A044476CD38BA7D5C9B8E8F19417A13B01C1"
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "-3.0120000001701"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rPx6Rbh8fStXeP3LwECBisownN2ZyMyzYS",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "bd5"
|
||||
},
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "7345788A2C9121EB8168D2755950887CED3887CCDBC882015BC070A61C2AD1DA",
|
||||
"PreviousFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "-0.0000000001701"
|
||||
}
|
||||
},
|
||||
"PreviousTxnID": "B4726FC087FAB3DB3578A34095B96F9055075A86A16CE741B406D91202685998",
|
||||
"PreviousTxnLgrSeq": 86722015
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "-52157.74818800332"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rBTwLga3i2gz3doX6Gva3MgEV8ZCD8jjah",
|
||||
"value": "1000000000"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "b29"
|
||||
},
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "8250CE37F6495903C1F7D16E072E8823ECE06FA73F011A0F8D79D5626BF581BB",
|
||||
"PreviousFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "-52160.76470600332"
|
||||
}
|
||||
},
|
||||
"PreviousTxnID": "B4726FC087FAB3DB3578A34095B96F9055075A86A16CE741B406D91202685998",
|
||||
"PreviousTxnLgrSeq": 86722015
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rPx6Rbh8fStXeP3LwECBisownN2ZyMyzYS",
|
||||
"Balance": "52479871",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 2,
|
||||
"Sequence": 86586866
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "9D398F1DEA77448C78196D6B01289A13D32DFCB4F9023A2A06338F893FA85521",
|
||||
"PreviousFields": {
|
||||
"Balance": "57479871",
|
||||
"OwnerCount": 3
|
||||
},
|
||||
"PreviousTxnID": "DCB061EC44BBF73BBC20CE0432E9D8D7C4B8B28ABA8AE5A5BA687476E7A796EF",
|
||||
"PreviousTxnLgrSeq": 86724050
|
||||
}
|
||||
},
|
||||
{
|
||||
"DeletedNode": {
|
||||
"FinalFields": {
|
||||
"ExchangeRate": "4e1566cbcc208000",
|
||||
"Flags": 0,
|
||||
"RootIndex": "DFA3B6DDAB58C7E8E5D944E736DA4B7046C30E4F460FD9DE4E1566CBCC208000",
|
||||
"TakerGetsCurrency": "0000000000000000000000000000000000000000",
|
||||
"TakerGetsIssuer": "0000000000000000000000000000000000000000",
|
||||
"TakerPaysCurrency": "0000000000000000000000005553440000000000",
|
||||
"TakerPaysIssuer": "0A20B3C85F482532A9578DBB3950B85CA06594D1"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "DFA3B6DDAB58C7E8E5D944E736DA4B7046C30E4F460FD9DE4E1566CBCC208000"
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 5,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
}
|
||||
```
|
||||
|
||||
{% code-snippet file="/_api-examples/metadata/cross-currency-payment.json" language="json" /%}
|
||||
|
||||
## AffectedNodes
|
||||
|
||||
@@ -32,6 +205,7 @@ labels:
|
||||
|
||||
これらの各フィールドの値は、レジャーエントリに行われた変更を記述するJSONオブジェクトです。
|
||||
|
||||
|
||||
### CreatedNodeのフィールド
|
||||
|
||||
`CreatedNode`オブジェクトは次のフィールドを含みます。
|
||||
@@ -40,7 +214,8 @@ labels:
|
||||
|:------------------|:--------------------|:-------------------------------------|
|
||||
| `LedgerEntryType` | 文字列 | 作成された[レジャーエントリの種類](../ledger-data/ledger-entry-types/index.md)。 |
|
||||
| `LedgerIndex` | 文字列 - [ハッシュ][] | レジャーの[状態ツリー](../../../concepts/ledgers/index.md)内のこの[レジャーエントリのID](../ledger-data/common-fields.md)。**注意:** 名前が非常に似ていますがこれは[レジャーインデックス](../data-types/basic-data-types.md#レジャーインデックス)とは**異なります**。 |
|
||||
| `NewFields` | オブジェクト | 新しく作成されたレジャー エントリの内容を示すフィールド。どのフィールドが存在するかは、作成されたレジャーエントリの種類によって異なります。 |
|
||||
| `NewFields` | オブジェクト | 新しく作成されたレジャーエントリの内容を示すフィールド。どのフィールドが存在するかは、作成されたレジャーエントリの種類によって異なります。 |
|
||||
|
||||
|
||||
### DeletedNodeのフィールド
|
||||
|
||||
@@ -52,6 +227,7 @@ labels:
|
||||
| `LedgerIndex` | 文字列 - [ハッシュ][] | レジャーの[状態ツリー](../../../concepts/ledgers/index.md)内のこの[レジャーエントリのID](../ledger-data/common-fields.md)。**注意:** 名前が非常に似ていますがこれは[レジャーインデックス](../data-types/basic-data-types.md#レジャーインデックス)とは**異なります** |
|
||||
| `FinalFields` | オブジェクト | 削除されたレジャーエントリの最後の内容を示すフィールド。どのフィールドが存在するかは、削除されたレジャーエントリの種類によって異なります。 |
|
||||
|
||||
|
||||
### ModifiedNodeのフィールド
|
||||
|
||||
`ModifiedNode`オブジェクトは次のフィールドを含みます。
|
||||
@@ -65,11 +241,12 @@ labels:
|
||||
| `PreviousTxnID` | 文字列 - [ハッシュ][] | _(省略可能)_ このレジャーエントリを変更する前のトランザクションの[識別用ハッシュ][]。`PreviousTxnID`フィールドを持たないレジャーエントリの種類では省略されます。 |
|
||||
| `PreviousTxnLgrSeq` | 数値 - [レジャーインデックス][] | _(省略可能)_ このレジャーエントリを変更する前のトランザクションを含むレジャーバージョンの[レジャーインデックス][]。`PreviousTxnLgrSeq`フィールドを持たないレジャーエントリの種類では省略されます。 |
|
||||
|
||||
**注記:** 変更されたレジャーエントリに`PreviousTxnID`フィールドと`PreviousTxnLgrSeq`フィールドがある場合、トランザクションは常にトランザクションの識別ハッシュとトランザクションを含むレジャーバージョンのインデックスでそれらを更新しますが、これらのフィールドの新しい値は`ModifiedNode`オブジェクトの`FinalFields`にはリストされず、以前の値はネストされた`PreviousFields`オブジェクトではなく `ModifiedNode` オブジェクトのトップレベルにリストされます。
|
||||
**注記:** 変更されたレジャーエントリに`PreviousTxnID`フィールドと`PreviousTxnLgrSeq`フィールドがある場合、トランザクションは常にトランザクションの識別ハッシュとトランザクションを含むレジャーバージョンのインデックスでそれらを更新しますが、これらのフィールドの新しい値は`ModifiedNode`オブジェクトの`FinalFields`にはリストされず、以前の値はネストされた`PreviousFields`オブジェクトではなく`ModifiedNode`オブジェクトのトップレベルにリストされます。
|
||||
|
||||
|
||||
## NFTのフィールド
|
||||
|
||||
NFTを含むトランザクション（`tx` と `account_tx`）はメタデータに以下のフィールドを含むことができます。これらの値はリクエスト時にサーバによって追加され、ハッシュ化されたバイナリメタデータには格納されません。
|
||||
NFTを含むトランザクション（`tx`と`account_tx`）はメタデータに以下のフィールドを含むことができます。これらの値はリクエスト時にサーバによって追加され、ハッシュ化されたバイナリメタデータには格納されません。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:--------------------|:--------------------------|:---------------------------|
|
||||
|
||||
@@ -42,13 +42,14 @@ Paymentは、[アカウントを作成](#アカウントの作成)する唯一
|
||||
|
||||
| フィールド | JSONの型 | [内部の型][] | 説明 |
|
||||
|:---------------|:--------------|:------------------|:-----------------|
|
||||
| Amount | [通貨額][] | Amount | 送金する通貨額。XRP以外の金額の場合、入れ子フィールドの名前では、アルファベットの小文字のみ使用してください。[**tfPartialPayment**フラグ](#paymentのフラグ)が設定されている場合は、この金額を _上限_ とする金額を送金します。 |
|
||||
| Destination | 文字列 | AccountID | 支払いを受取るアカウントの一意アドレス。 |
|
||||
| DestinationTag | 数値 | UInt32 | _（省略可）_ 宛先（支払先となる、ホスティングされている受取人）への支払い理由を明確にするための任意のタグ。 |
|
||||
| InvoiceID | 文字列 | Hash256 | _（省略可）_ この支払いの具体的な理由または識別子を表現する任意の256ビットハッシュ。 |
|
||||
| Paths | パス配列の配列 | PathSet | （省略可。自動入力可能）このトランザクションに使用される[支払いパス](../../../../concepts/tokens/fungible-tokens/paths.md)の配列。XRP間のトランザクションでは省略する必要があります。 |
|
||||
| SendMax | [通貨額][] | Amount | _（省略可）_ [送金手数料](../../../../concepts/tokens/transfer-fees.md)、為替レート、[スリッページ](http://en.wikipedia.org/wiki/Slippage_%28finance%29)を含め、このトランザクションに関して支払い元通貨での負担を許容する上限額。[トランザクションの送信コストとして消却されるXRP](../../../../concepts/transactions/transaction-cost.md)は含めないでください。XRP以外の金額の場合、入れ子フィールドの名前では、アルファベットの小文字のみ使用してください。クロスカレンシー支払いまたは複数のトークンを伴う支払いについては、このフィールドを入力する必要があります。XRP間の支払いでは省略する必要があります。 |
|
||||
| DeliverMin | [通貨額][] | Amount | _（省略可）_ このトランザクションで送金する、宛先通貨での最少金額。[Partial Payments](../../../../concepts/payment-types/partial-payments.md)の場合のみ有効になります。XRP以外の金額の場合、入れ子フィールドの名前では、アルファベットの小文字のみ使用してください。 |
|
||||
| `Amount` | [通貨額][] | Amount | 送金する通貨額。XRP以外の金額の場合、入れ子フィールドの名前では、アルファベットの小文字のみ使用してください。[**tfPartialPayment**フラグ](#paymentのフラグ)が設定されている場合は、この金額を _上限_ とする金額を送金します。 |
|
||||
| `Destination` | 文字列 | AccountID | 支払いを受取るアカウントの一意アドレス。 |
|
||||
| `DestinationTag` | 数値 | UInt32 | _（省略可）_ 宛先（支払先となる、ホスティングされている受取人）への支払い理由を明確にするための任意のタグ。 |
|
||||
| `InvoiceID` | 文字列 | Hash256 | _（省略可）_ この支払いの具体的な理由または識別子を表現する任意の256ビットハッシュ。 |
|
||||
| `Paths` | パス配列の配列 | PathSet | （省略可。自動入力可能）このトランザクションに使用される[支払いパス](../../../../concepts/tokens/fungible-tokens/paths.md)の配列。XRP間のトランザクションでは省略する必要があります。 |
|
||||
| `SendMax` | [通貨額][] | Amount | _（省略可）_ [送金手数料](../../../../concepts/tokens/transfer-fees.md)、為替レート、[スリッページ](http://en.wikipedia.org/wiki/Slippage_%28finance%29)を含め、このトランザクションに関して支払い元通貨での負担を許容する上限額。[トランザクションの送信コストとして消却されるXRP](../../../../concepts/transactions/transaction-cost.md)は含めないでください。XRP以外の金額の場合、入れ子フィールドの名前では、アルファベットの小文字のみ使用してください。クロスカレンシー支払いまたは複数のトークンを伴う支払いについては、このフィールドを入力する必要があります。XRP間の支払いでは省略する必要があります。 |
|
||||
| `DeliverMin` | [通貨額][] | Amount | _（省略可）_ このトランザクションで送金する、宛先通貨での最少金額。[Partial Payments](../../../../concepts/payment-types/partial-payments.md)の場合のみ有効になります。XRP以外の金額の場合、入れ子フィールドの名前では、アルファベットの小文字のみ使用してください。 |
|
||||
|
||||
|
||||
## Paymentの種類
|
||||
|
||||
@@ -86,7 +87,7 @@ Payment型のトランザクションでは、資金供給のないアドレス
|
||||
|
||||
## パス
|
||||
|
||||
`Paths`フィールドが存在する場合、Pathフィールドには、 _パスセット_ （パス配列の配列）が記述されていなければなりません。個々のパスは、さまざまな仲介アカウントやオーダーブックを経由して、送信者から受信者へと価値が1つの方向へ流れることを表します。単一のトランザクションで、複数のパスを使用する可能性もあります。例えば、トランザクションで複数のオーダーブックを使用して、最も有利なレートで通貨を交換する場合です。
|
||||
`Paths`フィールドが存在する場合、Pathフィールドには、 _パスセット_ （パス配列の配列）が記述されていなければなりません。個々のパスは、さまざまな仲介アカウントやオーダーブックを経由して、送信者から受信者へと価値が1つの方向へ流れることを表します。単一のトランザクションで、複数のパスを使用する可能性もあります。例えば、トランザクションで複数のオーダーブックやAMMを使用して、最も有利なレートで通貨を交換する場合です。
|
||||
|
||||
以下の場合を含め、直接の支払いでは`Paths`フィールドを省略する必要があります。
|
||||
|
||||
@@ -105,7 +106,7 @@ Payment型のトランザクションについては、[`Flags`フィールド](
|
||||
|
||||
| フラグの名前 | 16進値 | 10進値 | 説明 |
|
||||
|:-------------------|:-------------|:--------------|:-----------------------------|
|
||||
| `tfNoDirectRipple` | `0x00010000` | 65536 | デフォルトパスを使用せず、`Paths`フィールドに含まれているパスのみ使用します。これによりトランザクションは強制的に裁定機会を活用することになります。ほとんどのクライアントでは、これは必要ありません。 |
|
||||
| `tfNoRippleDirect` | `0x00010000` | 65536 | デフォルトパスを使用せず、`Paths`フィールドに含まれているパスのみ使用します。これによりトランザクションは強制的に裁定機会を活用することになります。ほとんどのクライアントでは、これは必要ありません。 |
|
||||
| `tfPartialPayment` | `0x00020000` | 131072 | `SendMax`を超えていないのに指定された`Amount`を送金できない場合、即座に失敗とするのではなく、受取られる額を減額します。詳細は、[Partial Payments](../../../../concepts/payment-types/partial-payments.md)をご覧ください。 |
|
||||
| `tfLimitQuality` | `0x00040000` | 262144 | すべての変換で、入力と出力との比率が`Amount`と`SendMax`との比率と同一であるか、さらに有利となるパスのみを採用します。詳細は、[クオリティの制限](#クオリティの制限)をご覧ください。 |
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ parent: tasks.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# 専門的な支払いタイプの使用
|
||||
# 高度な支払い機能の利用
|
||||
|
||||
EscrowやPayment Channelなどの高度な機能を使用して、XRP Ledgerでスマートアプリケーションを構築しましょう。
|
||||
|
||||
|
||||
41
@i18n/ja/docs/tutorials/index.md
Normal file
41
@i18n/ja/docs/tutorials/index.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
seo:
|
||||
description: 開発者向けの暗号資産ウォレットやブロックチェーンのチュートリアルで、XRP Ledgerを使った開発方法を学びましょう。
|
||||
---
|
||||
# 暗号資産ウォレットやブロックチェーン開発のチュートリアル
|
||||
|
||||
XRP Ledgerを学び、使い始め、そして高度なユースケースで使用するための手順を説明します。
|
||||
|
||||
## SDKを使って始める
|
||||
|
||||
これらのチュートリアルでは、お好きなプログラミング言語を使って、XRP Ledgerに接続するアプリケーションを構築するための基礎について説明します。
|
||||
|
||||
{% card-grid %}
|
||||
|
||||
{% xrpl-card title="Javascript" body="クライアントライブラリxrpl.jsを使用" href="/docs/tutorials/javascript/" image="/img/logos/javascript.svg" imageAlt="Javascript logo" /%}
|
||||
|
||||
{% xrpl-card title="Python" body="Pythonライブラリxrpl.pyを使用" href="/docs/tutorials/python/" image="/img/logos/python.svg" imageAlt="Python logo" /%}
|
||||
|
||||
<br/>
|
||||
|
||||
{% xrpl-card title="Java" body="Javaライブラリを使用" href="/docs/tutorials/java/" image="/img/logos/java.svg" imageAlt="Java logo" /%}
|
||||
|
||||
{% xrpl-card title="PHP" body="PHPライブラリXRPL_PHPを使用" href="/docs/tutorials/php/" image="/img/logos/php.svg" imageAlt="PHP logo" /%}
|
||||
|
||||
{% xrpl-card title="HTTP & WebSocket API" body="コアサーバのAPIを通じてXRP Ledgerに直接アクセス" href="/docs/tutorials/http-websocket-apis/" image="/img/logos/globe.svg" imageAlt="globe icon" /%}
|
||||
|
||||
{% /card-grid %}
|
||||
|
||||
## 使い方
|
||||
|
||||
これらの例では、順を追って操作方法を説明しています。
|
||||
|
||||
{% card-grid %}
|
||||
|
||||
{% xrpl-card title="アカウントの設定" body="XRP Ledgerアカウントを設定して、自由に支払いを行いましょう。" href="/docs/tutorials/how-tos/manage-account-settings/" /%}
|
||||
{% xrpl-card title="高度な支払い機能" body="エスクローやペイメントチャネルなどの高度な支払い機能を使って、XRP Ledger上に新しいアプリケーションを構築しましょう。" href="/docs/tutorials/how-tos/use-specialized-payment-types/" /%}
|
||||
{% xrpl-card title="トークンの利用" body="XRP Ledgerでトークン(代替可能またはそれ以外)を作成し、取引しましょう。" href="/docs/tutorials/how-tos/use-tokens/" /%}
|
||||
{% xrpl-card title="XRPLサイドチェーンの利用" body="メインネットからXRPLサイドチェーンにXRPやトークンをブリッジしましょう。" href="/docs/tutorials/how-tos/use-xrpl-sidechains/" /%}
|
||||
|
||||
|
||||
{% /card-grid %}
|
||||
@@ -90,7 +90,7 @@ Rippleが推奨するベストプラクティスに従い、Alpha Exchangeは、
|
||||
|
||||
* オプションとして、コールドウォレットとホットウォレットの間で追加のセキュリティ層を提供する、1つ以上のウォームウォレット。ホットウォレットとは異なり、ウォームウォレットのシークレットキーはオンラインである必要はありません。さらに、ウォームウォレットのシークレットキーを複数の人に分散し、[マルチシグ](../../concepts/accounts/multi-signing.md)を導入してセキュリティを強化することもできます。
|
||||
|
||||
不正使用されたウォームウォレットによって発生するおそれのある結果についての詳細は、[スタンバイアドレスの漏えい](../../concepts/accounts/account-types.md#スタンバイアドレスの漏えい)をご覧ください。
|
||||
不正使用されたウォームウォレットによって発生するおそれのある結果についての詳細は、[待機アドレスの漏えい](../../concepts/accounts/account-types.md#待機アドレスの漏えい)をご覧ください。
|
||||
|
||||
|
||||
関連項目:
|
||||
|
||||
@@ -86,7 +86,7 @@ XLSドラフトを作成した後、その変更にAmendmentが必要かどう
|
||||
|
||||
## コードのフローチャート
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
@@ -19,117 +19,107 @@ XRPL Dev Portalでは、開発者が開発を開始するためのサンプル
|
||||
|
||||
本プロジェクトの公式リポジトリは<https://github.com/XRPLF/xrpl-dev-portal>となっています。投稿の著作権はそれぞれの投稿者に帰属しますが、MIT[ライセンス](https://github.com/XRPLF/xrpl-dev-portal/blob/master/LICENSE)の下で提供されなければなりません。
|
||||
|
||||
|
||||
|
||||
## リポジトリの構成
|
||||
|
||||
***TODO: Update this translation***
|
||||
- `_api-examples/` - APIリクエストやレスポンスのサンプル(特にドキュメントで使用されているもの)
|
||||
- `_code-samples/` - ドキュメントで使用されているサンプルコード(可能な限り完全に動作するスクリプト)
|
||||
- `@i18n` - 英語以外の翻訳コンテンツ
|
||||
- `@theme` - MarkdocのコンテンツやReactのカスタムページで使用されるコンポーネントのオーバーライドやカスタムコンポーネント
|
||||
- `about/` - 概要セクションのソースファイル
|
||||
- `blog/` - XRPL開発者ブログのソースファイル
|
||||
- `community/` - コミュニティセクションのソースファイル
|
||||
- `docs/` - ドキュメントをビルドするためのソースファイル(ほとんどがMarkdownファイル)
|
||||
- `docs/_snippets/` - ドキュメント内で再利用可能なテキスト
|
||||
- `docs/img/` - ドキュメント内で利用する図やその他の画像
|
||||
- `docs/img/_sources/` - ドキュメント内で利用する画像のソースファイル(存在する場合)
|
||||
- `locale/` - **廃止** 以前利用されていた翻訳用のファイル
|
||||
- `resources/` - リソースセクションのソースファイル
|
||||
- `shared/` - CodeMirrorなどの依存関係の設定ファイル
|
||||
- `static/` - Webサイトのテンプレートやテーマで使用される静的ファイル
|
||||
- `styles/` - カスタムCSS用のSCSSのソースファイル
|
||||
- `redirects.yaml` - 以前利用されていたパスから現在のコンテンツへのリダイレクトの定義
|
||||
- `redocly.yaml` - Webサイトにの主要な設定ファイル
|
||||
- `sidebars.yaml` - ドキュメントおよびリソースセクションのサイドバーの定義
|
||||
- `top-nav.yaml` - ナビゲーションバーの定義
|
||||
|
||||
- `_api-examples/` - Sample API requests and responses, especially ones used in the documentation.
|
||||
- `_code-samples/` - Code samples used or referenced by the documentation. Where possible, these are fully functional / executable scripts.
|
||||
- `@i18n` - Translations into languages other than English. Currently, only Japanese.
|
||||
- `@theme` - Overrides and custom components used in Markdoc contents as well as custom React pages.
|
||||
- `about/` - Source files for the About section's pages.
|
||||
- `blog/` - Source files for the XRPL Dev Blog.
|
||||
- `community/` - Source files for the Community section's pages.
|
||||
- `docs/` - Source files used to build the documentation. Mostly in Markdown.
|
||||
- `docs/_snippets/` - Reusable pieces of text used in the documentation.
|
||||
- `docs/img/` - Diagrams and other images used in the documentation.
|
||||
- `docs/img/_sources/` - Source files for images used in the documentation, where available.
|
||||
- `locale/` - **DEPRECATED** Old localization files.
|
||||
- `resources/` - Source files for the Resources section's pages.
|
||||
- `shared/` - Configuration files for some dependencies like CodeMirror.
|
||||
- `static/` - Static files used by the site's templates and theme.
|
||||
- `styles/` - SCSS source files for custom CSS.
|
||||
- `redirects.yaml` - Definitions of redirects from old site URLs to current paths.
|
||||
- `redocly.yaml` - Main config file for the site.
|
||||
- `sidebars.yaml` - Defines sidebars for the Documentation and Resources sections.
|
||||
- `top-nav.yaml` - Defines the main top nav elements.
|
||||
|
||||
## プルリクエストが承認されるための条件
|
||||
|
||||
レビューやマージが承認される前に、それぞれのプルリクエストは以下の条件を満たしていなければなりません。
|
||||
|
||||
- インテグレーションテストに合格すること。
|
||||
- レビューの準備が整うまで、[Draft](https://github.blog/2019-02-14-introducing-draft-pull-requests/)としてください。
|
||||
- このリポジトリの[コード規約](https://github.com/XRPLF/xrpl-dev-portal/blob/master/CODE-OF-CONDUCT.ja.md)を遵守してください。
|
||||
|
||||
## Dactylのセットアップ
|
||||
## Redoclyのセットアップ
|
||||
|
||||
ポータルは[Dactyl](https://github.com/ripple/dactyl)を使用して構築されています。
|
||||
このポータルはRecokly Realmを使用して構築されています。Realmは現在クローズドベータ版です。ローカル開発環境にインストールするには、Node.js(バージョン20が推奨)とNPMが必要です。
|
||||
|
||||
Dactylには[Python 3](https://python.org/)が必要です。[pip](https://pip.pypa.io/en/stable/)を使ってインストールしてください：
|
||||
次のコマンドを実行して、Realmとその他の必要な依存関係をインストールできます。
|
||||
|
||||
```
|
||||
pip3 install dactyl
|
||||
```sh
|
||||
npm i
|
||||
```
|
||||
|
||||
## サイトの構築
|
||||
|
||||
このリポジトリでは、[**Dactyl**](https://github.com/ripple/dactyl)を使用して、すべてのドキュメントのHTMLをビルドしています。[Dactylのセットアップ](#dactylのセットアップ)を行った後、プロジェクトのルートディレクトリからサイトをビルドすることができます。
|
||||
依存関係のインストール後、次のコマンドを実行してローカル開発サーバを起動できます。
|
||||
|
||||
```
|
||||
dactyl_build
|
||||
```sh
|
||||
npm run start
|
||||
```
|
||||
|
||||
生成されたコンテンツは`out/`ディレクトリに出力されます。これらのコンテンツはウェブブラウザでファイルとして開いたり、ウェブサーバで静的コンテンツとして扱うことができます。
|
||||
ブラウザでhttp://localhost:4000/にアクセスしてプレビューを表示できます。
|
||||
|
||||
ルートディレクトリからリンクチェックやスタイルチェックを実行することもできます。
|
||||
|
||||
リンクチェックは出力フォルダを空にしてからビルドしてください。
|
||||
|
||||
```
|
||||
dactyl_link_checker
|
||||
```
|
||||
|
||||
スタイルチェックは実験的なものです。
|
||||
|
||||
```
|
||||
dactyl_style_checker
|
||||
```
|
||||
|
||||
## 設定ファイルのフォーマット
|
||||
|
||||
このリポジトリでは、`dactyl-config.yml`ファイルのメタデータとページの[frontmatter](https://dactyl.link/frontmatter.html)を使って、ヘッダー、フッター、サイドバー、パンくずリストなどのナビゲーション要素を生成します。
|
||||
Realmの設定ファイルは、サイト内のナビゲーション要素を生成するために使用されます。これには、ヘッダー、フッター、サイドバー、パンくずリストが含まれます。
|
||||
|
||||
新しいページを追加する場合、`dactyl-config.yml`ファイルのpages配列の適切な位置に追加する必要があります。追加例は次のようになります。
|
||||
新しいページを追加する場合、そのページを`sidebars.yaml`ファイルに追加する必要があります。ドキュメントとブログ用のサイドバーのファイルがあります。以下は、ネストされた子ページがないページの項目の例です。
|
||||
|
||||
```yaml
|
||||
- md: concepts/the-rippled-server/the-rippled-server.md
|
||||
targets:
|
||||
- en
|
||||
- ja # 翻訳コンテンツがない場合、全てのターゲットを対象とします。
|
||||
- page: concepts/consensus-protocol/index.md
|
||||
```
|
||||
|
||||
Markdownファイル自体は、以下のようなfrontmatterで始まる必要があります。
|
||||
|
||||
```yaml
|
||||
---
|
||||
html: the-rippled-server.html
|
||||
parent: concepts.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: rippled is the core peer-to-peer server that manages the XRP Ledger. This section covers concepts that help you learn the "what" and "why" behind fundamental aspects of the rippled server.
|
||||
---
|
||||
```
|
||||
|
||||
少なくとも、ほとんどのページには `html`、`parent`、`blurb` フィールドが必要です(さらに、設定ファイルでは`md`フィールドと`targets`フィールドも必要です)。ここに、またはページの設定ファイルのエントリに任意のキーと値のペアを記述することができますが、以下のものが関係しています。
|
||||
Markdownファイルのページは、[frontmatterスタンザ](#frontmatterのフィールド)で始まる必要があります。
|
||||
|
||||
### 規約
|
||||
|
||||
ページを作成する際には、以下の規約に従ってください。
|
||||
|
||||
- HTMLのファイル名とMDのファイル名は、拡張子を除いて完全に一致していなければなりません。
|
||||
- ファイル名は"and"や"the"のような単語を含め、ページのタイトルと密接に一致する必要がありますが、スペースや句読点の代わりにハイフンを使用し、すべて小文字にする必要があります。例えば、`cash-a-check-for-an-exact-amount.md`のようにします。ページのタイトルを変更した場合は、ファイル名も変更する必要があります。(すでに別のURLで公開されている場合は、古いURLからのリダイレクトを残してください)
|
||||
- HTMLのファイル名とMDのファイル名は、拡張子を除いて完全に一致していなければなりません。ファイル名は"and"や"the"のような単語を含め、ページのタイトルと密接に一致する必要がありますが、スペースや句読点の代わりにハイフンを使用し、すべて小文字にする必要があります。例えば、`cash-a-check-for-an-exact-amount.md`のようにします。ページのタイトルを変更した場合は、ファイル名も変更する必要があります。(すでに別のURLで公開されている場合は、古いURLからのリダイレクトを残してください)
|
||||
- カテゴリ内のページは、そのカテゴリの名前のサブフォルダに配置されるべきですが、親ディレクトリにも同じ単語が含まれている場合は、より簡潔にすることができます。ファイル名は`index.md`で、タイトルはフォルダ名に似ている必要があります。例えば、"Protocol Reference"のインデックスページは`references/protocol/index.md`にあります。
|
||||
- 常にh1ヘッダーでページを始めます。
|
||||
- ページの一番上のh1アンカーにはリンクせず、アンカーなしでページ自体にリンクしてください。これは翻訳時のリンク切れを防ぐのに役立ちます。以降のヘッダーへのリンクは問題ありません。
|
||||
- ページのタイトルに書式( _italics_ や`code font`など)を使わないでください。
|
||||
- ページのタイトルに書式( _斜体_ や`コード`など)を使わないでください。
|
||||
- Markdownファイルのテキストを折り返さないでください。
|
||||
- コードサンプルの場合、行は80文字以下になるようにしてください。
|
||||
- コードサンプルの場合、1行は80文字以下になるようにしてください。
|
||||
- 迷ったら、[Ciro SantilliのMarkdownスタイルガイド (Writability Profile)](https://cirosantilli.com/markdown-style-guide/)に従ってください。
|
||||
- カテゴリ内のページはそのカテゴリの名前のサブフォルダにあるべきですが、（特にページのタイトルが親ディレクトリにもある単語を含んでいる場合は）あまり冗長でなく、ファイル名`index.md`とフォルダ名に似たタイトルを持つべきです。例えば、「プロトコルリファレンス」のインデックスページは`references/protocol/index.md`です。
|
||||
|
||||
- Markdownやコードサンプルでは、インデントにタブ文字を使用しないでください。**JavaScript**のコードサンプルでは、1字下げにつき2個のスペースを使用してください。
|
||||
- テキストファイルは改行文字で終わるようにしてください。(一部のテキストエディタはこれを自動的に処理します。)ファイルはBOMなしのUTF-8でエンコードしてください。
|
||||
|
||||
### 新機能
|
||||
|
||||
新機能を文書化する場合、その機能が導入されたプログラムのバージョンを示すバッジを含めてください。バッジタグは以下の構造です。
|
||||
|
||||
`{badge href="myurl" date="<リリース日>"}新規: <プログラム> <バージョン番号>{% /badge%}`
|
||||
|
||||
例えば次のようなバッジ定義になります。
|
||||
|
||||
`{% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" date="February 18, 2024" %}新規: Clio v2.0.0{% /badge %}`
|
||||
|
||||
次のように表示されます。 {% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" date="February 18, 2024" %}新規: Clio v2.0.0{% /badge %}
|
||||
|
||||
When updating a feature, replace _New in:_ with _Updated in:_. For example, the following badge definition:
|
||||
|
||||
機能の更新の場合、_新規:_ を _更新:_ に置き換えてください。例えば、次のバッジ定義となります。
|
||||
|
||||
`{% badge href="https://github.com/XRPLF/clio/releases/tag/2.1.0" date="May 4, 2024" %} 更新: Clio v2.1.0{% /badge %}`
|
||||
|
||||
次のように表示されます。 {% badge href="https://github.com/XRPLF/clio/releases/tag/2.1.0" date="May 4, 2024" %} 更新: Clio v2.1.0{% /badge %}
|
||||
|
||||
2年以上前の新規/更新バッジは削除するのがベストプラクティスです。
|
||||
|
||||
### 技術用語
|
||||
|
||||
@@ -156,29 +146,230 @@ seo:
|
||||
|
||||
## Frontmatterのフィールド
|
||||
|
||||
このリポジトリのMarkdownファイルのfronmatterは任意のキーと値のペアを含むことができます。以下のフィールドは特定の用途や意味を持ちます。
|
||||
***Note: Realmのfrontmatter仕様の詳細は完全には文書化されていません。Realmがクローズドベータを終了したら、リンクを更新する必要があります。***
|
||||
|
||||
| フィールド | 型 | 内容 |
|
||||
|:---------------------|:-----------------|:-----------------------------------|
|
||||
| `html` | String | ページの出力ファイル名。`.html`で終わり、ターゲット内で一意でなければなりません。翻訳版のページでは、ファイル名は英語版のページと同じにしてください。 |
|
||||
| `parent` | String | ページの「親」ページの`html`の値。このページがナビゲーションのどこに表示されるかを示します。 |
|
||||
| `blurb` | String | ページの要約文(プレーンテキストのみ)。ランディングページやソーシャルメディア上でリンクを展開する際のメタデータなど、さまざまな場所に表示されます。 |
|
||||
| `name` | String | ページ名(プレーンテキストのみ)。 Markdownコンテンツのあるファイルでは、Dactylがコンテンツの最初の行のヘッダーから自動的に検出できるため、これを省略する必要があります。これは通常、Markdownファイルを持たないランディングページやその他の特別なページでのみ提供されます。 |
|
||||
| `template` | String | このページで使用するテンプレートファイルのファイル名(`template/`ディレクトリ内)。ほとんどのページはデフォルトのテンプレートを使用します。`pagetype-category.html.jinja`テンプレートは最後に子ページのリストを表示します。特別な、あるいは特にユニークなレイアウトを持つページには、個別のテンプレートが必要になることがあります(通常、`page-`で始まります)。 |
|
||||
| `status` | String | XRP Ledgerメインネットでまだ有効になっていない修正に関連するページでは、`not_enabled`を使用します。これにより、ナビゲーションのページの横にツールチップ付きの"フラスコ"バッジが表示されます。 |
|
||||
| `nav_omit` | Boolean | ナビゲーション要素にこのページを表示しないようにするには`true`を使用します。 |
|
||||
| `top_nav_omit` | Boolean | ページトップのドロップダウンナビゲーションに表示しないようにするには、`true`を使用します。 |
|
||||
| `top_nav_level` | Number | トップナビのドロップダウンでページのインデントレベルを調整します。レベル`2`は、ドロップダウン内でその上のページの子のように表示されるようにインデントされます。 |
|
||||
| `sidebar` | String | U左右のサイドバーを非表示にするには、`disabled`を使用します(ページがベーステンプレートから派生したテンプレートを使用している場合)。 |
|
||||
| `fb_card` | String | Facebookでこのページへのリンクを展開する際に使用する画像のファイル名（`assets/img/`内）。 |
|
||||
| `twitter_card` | String | Twitterでこのページへのリンクを展開する際に使用する画像のファイル名（`assets/img/`内）。 |
|
||||
| `redirect_url` | String | `template: pagetype-redirect.html.jinja`でのみ使用します。ユーザがこのページに移動したときに、指定されたURLに自動的にリダイレクトします。 |
|
||||
| `cta_text` | String | このページにリンクする「call to action」ボタンに表示されるテキスト(特別なランディングページにて表示されます)。 |
|
||||
| `curated_anchors` | Array of Objects | 子ページと同様に、ランディングページに表示するためのアンカーです。配列の各オブジェクトは、人間が読める`name`フィールド(`"Available Modes"`など) と、リンク先のHTML IDを持つ`anchor`フィールド(`"#available-modes"`など)を持つ必要があります。 |
|
||||
| `skip_spell_checker` | Boolean | `true`を使用すると、Dactylのスタイルチェッカーがこのページのスペルチェックをスキップします。 |
|
||||
| `filters` | Array of Strings | このページで使用する追加フィルタのリストです。[フィルタ](https://github.com/ripple/dactyl/blob/master/README.md#filters)はPythonスクリプトで、ページ内容の事前または事後の追加処理を行います。 |
|
||||
| `canonical_url` | String | クエリパラメータを受け取るページの正規URLを提供します。検索エンジンやその他のツールは、ページにリンクする際にこれを使用する可能性があります。 |
|
||||
| `embed_xrpl_js` | Boolean | 最新版の[xrpl.js](https://js.xrpl.org)をこのページで読み込むには`true`を使用してください。 |
|
||||
MarkdownファイルのFrontmatterには、以下のような内容が含まれます。
|
||||
|
||||
```yaml
|
||||
---
|
||||
metadata:
|
||||
indexPage: true # 自動生成された子ページのリストを含めたい場合、追加してください。
|
||||
seo:
|
||||
description: rippledはXRP Ledgerを管理するコアとなるピアツーピアサーバです。このセクションでは、rippledサーバの基本的な機能の背景にある「要素」と「その理由」を学ぶのに役立つ概念について説明します。
|
||||
---
|
||||
```
|
||||
|
||||
サイト内の一部のページには、以前の(Dactyl)ツールチェーンからのメタデータが残っている場合があります。これらのフィールドは効果がないため、新しいページから省略することができます。
|
||||
|
||||
### 次へと前へのボタン
|
||||
|
||||
ドキュメントとブログページには、ページの下部に「次へ」ボタンと「前へ」ボタンがあります。
|
||||
|
||||
これらのボタンが不要な場合は、ページのfrontmatterを更新して無効にすることができます。
|
||||
|
||||
```yaml
|
||||
---
|
||||
theme:
|
||||
navigation:
|
||||
nextButton:
|
||||
hide: true
|
||||
---
|
||||
```
|
||||
|
||||
## Markdocのコンポーネント
|
||||
|
||||
これらのファイルは[Markdoc](https://markdoc.dev/)で処理されるため、`{% ... %}`構文で特別なタグを含めることができます。Redoclyの組み込みタグに加えて、このリポジトリには`/@theme/markdoc/`に定義されたいくつかのカスタムタグがあります。
|
||||
|
||||
### グラフィック
|
||||
|
||||
`/docs/img`ディレクトリにグラフィックを保存します。グラフィックを埋め込むには、次の構文を使用します。
|
||||
|
||||
``
|
||||
|
||||
例えば、``は次のように表示されます。
|
||||
|
||||
|
||||
|
||||
### ビデオ
|
||||
|
||||
ビデオはYouTubeに保存されます。アップロード後、埋め込み手順をコピーしてドキュメントに貼り付けることができます。
|
||||
|
||||
コンテンツにYouTubeビデオを埋め込むには、次の手順に従います。
|
||||
|
||||
1. YouTubeにビデオをアップロードします。
|
||||
2. ビデオページの**共有**ボタンをクリックします。
|
||||
3. **埋め込む**をクリックします。
|
||||
4. ポップアップ右下の**コピー**をクリックします。
|
||||
5. コンテンツに`<iframe>`要素を貼り付けます。
|
||||
|
||||
例えば、_Send Checks_ ビデオを埋め込むためのコードは次の通りです。
|
||||
|
||||
```
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/5zRBC7dGSaM?
|
||||
si=Mbi8diaFTDR2fc20" title="YouTube video player" frameborder="0" allow="accelerometer;
|
||||
autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
|
||||
referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
|
||||
```
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/5zRBC7dGSaM?
|
||||
si=Mbi8diaFTDR2fc20" title="YouTube video player" frameborder="0" allow="accelerometer;
|
||||
autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
|
||||
referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
|
||||
|
||||
### テーブル
|
||||
|
||||
Markdocは、テーブルを生成するための3つの異なる構文スタイルを提供します。
|
||||
|
||||
ほとんどの場合、列を区切るためにパイプ文字(|)を使用し、ハイフン3つ以上(---)を使用して列ヘッダを作成します。
|
||||
|
||||
```
|
||||
| | Head 1 |
|
||||
| ------- | ------ |
|
||||
| Label 1 | Val 1 |
|
||||
```
|
||||
|
||||
次のように表示されます。
|
||||
|
||||
| | Head 1 |
|
||||
| ------- | ------ |
|
||||
| Label 1 | Val 1 |
|
||||
|
||||
セルの幅は同じである必要はありません。自動的に列を整列し、必要に応じてテキストを折り返します。
|
||||
|
||||
```
|
||||
| Key | Value |
|
||||
| --- | ----- |
|
||||
| Name | H. G. Wells |
|
||||
| Genre | Science Fiction |
|
||||
| Hyperbole | The greatest story ever told! No one has ever written anything more important than this Victorian era classic. Oh, how swells the heart to ponder the heady philosophies introduced therein! |
|
||||
```
|
||||
|
||||
| Key | Value |
|
||||
| --- | ----- |
|
||||
| Name | H. G. Wells |
|
||||
| Genre | Science Fiction |
|
||||
| Hyperbole | The greatest story ever told! No one has ever written anything more important than this Victorian era classic. Oh, how swells the heart to ponder the heady philosophies introduced therein! |
|
||||
|
||||
ヘッダ行にコロンを使用して、列を左寄せ(:--)、中央寄せ(:-:)、または右寄せ(--:)に配置します。
|
||||
|
||||
```
|
||||
| Model | Color | Price |
|
||||
| :-: | :-- | --: |
|
||||
| Protexra | Electric Blue | 50,000 XRP |
|
||||
| Joatic | Hot Pink | 165,000 XRP |
|
||||
| Zhanu | Neon Green | 234,000 XRP |
|
||||
```
|
||||
|
||||
| Model | Color | Price |
|
||||
| :-: | :-- | --: |
|
||||
| Protexra | Electric Blue | 50,000 XRP |
|
||||
| Joatic | Hot Pink | 165,000 XRP |
|
||||
| Zhanu | Impetuous Green | 1,728,000 XRP |
|
||||
|
||||
左の列はデフォルトで太字になります。左の列に太字のラベルを表示したくない場合は、左の列を空にして、テーブルを1列目から始めてください。
|
||||
|
||||
```
|
||||
| | French | English | German |
|
||||
| --- | --- | --- | --- |
|
||||
| | Fromage | Cheese | Käse |
|
||||
| | Maux d'estomac | Stomach ache | Magenschmerzen |
|
||||
| | Cornichon | Pickle | Essiggurke |
|
||||
```
|
||||
|
||||
| | French | English | German |
|
||||
| --- | --- | --- | --- |
|
||||
| | Fromage | Cheese | Käse |
|
||||
| | Maux d'estomac | Stomach ache | Magenschmerzen |
|
||||
| | Cornichon | Pickle | Essiggurke |
|
||||
|
||||
可能な限り、これらの基本的なテーブルを使用してください。上記の例で提供されていない特別なフォーマットが本当に必要な場合は、HTML構文を使用してテーブルを作成できます。
|
||||
|
||||
### リンク
|
||||
|
||||
リンクは`[<リンクテキスト>](<URL>)`の構文を使用します。
|
||||
|
||||
例えば、次のように書きます。
|
||||
|
||||
`[XRPL.org](http://xrpl.org)で世界のあらゆる問題の解決策をご覧ください。`
|
||||
|
||||
次のように表示されます。
|
||||
|
||||
[XRPL.org](http://xrpl.org)で世界のあらゆる問題の解決策をご覧ください。
|
||||
|
||||
### 共通のリンク
|
||||
|
||||
共通的に引用されるページへのリンクを作成するには、`{% raw-partial file="/docs/_snippets/common-links.md /%}`タグをMarkdownファイルに追加し、`[account_infoメソッド][]`や`[Paymentトランザクション][]`などの参照スタイルのリンクを使用できます。common-linksファイルの内容はアルファベット順になっています。(以前はスクリプトで生成されていましたが、現在は手動で管理されています。)
|
||||
|
||||
### サンプルコード
|
||||
|
||||
サンプルコードを挿入する場合は、バッククォート(`)文字でコードを囲みます。例えば:
|
||||
|
||||
私のお気に入りのメソッドは`nft_info`です。
|
||||
|
||||
次のように表示されます。
|
||||
|
||||
私のお気に入りのメソッドは`nft_info`です。
|
||||
|
||||
長いコードブロックの場合は、言語名に続いて3つのバッククォート(```)を使用します。改行を入力し、サンプルコードを入力します。コードサンプルの最後に改行を入力し、3つのバッククォート(```)でブロックを閉じます。
|
||||
|
||||
例えば、
|
||||
|
||||
```javascript<br/>
|
||||
const prepared = await client.autofill({<br/>
|
||||
"TransactionType": "Payment",<br/>
|
||||
"Account": standby_wallet.address,<br/>
|
||||
"Amount": xrpl.xrpToDrops(sendAmount),<br/>
|
||||
"Destination": standbyDestinationField.value<br/>
|
||||
})
|
||||
```
|
||||
|
||||
次のように表示されます。
|
||||
|
||||
```javascript
|
||||
const prepared = await client.autofill({
|
||||
"TransactionType": "Payment",
|
||||
"Account": standby_wallet.address,
|
||||
"Amount": xrpl.xrpToDrops(sendAmount),
|
||||
"Destination": standbyDestinationField.value
|
||||
})
|
||||
```
|
||||
|
||||
### 部分的なコンテンツ
|
||||
|
||||
頻繁に使用するテキストや、ドキュメント内の複数の場所で定期的に更新が必要なテキストがある場合は、再利用のために_snippetファイルを作成できます。
|
||||
|
||||
`_snippet`ディレクトリにファイルを保存します。部分的なコンテンツを挿入するには、`{% partial file="<file url>" /%}`構文を使用します。
|
||||
|
||||
例えば、次のようなスニペット`/docs/_snippets/secret-key-warning.md`があります。
|
||||
|
||||
<blockquote>
|
||||
{% admonition type="warning" name="Caution" %}<br/>
|
||||
Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.<br/>
|
||||
{% /admonition %}
|
||||
</blockquote>
|
||||
|
||||
テキストを埋め込むには、`{% partial file="/docs/_snippets/secret-key-warning.md" /%}`タグを使用します。
|
||||
|
||||
例えば、
|
||||
|
||||
<blockquote>
|
||||
There I was, happy as a lark, skipping through the daisies, when I shyly handed my secret
|
||||
key to my one true love.
|
||||
|
||||
{% partial file="/docs/_snippets/secret-key-warning.md" /%}
|
||||
|
||||
Alas, if only I had heeded that sage advice, I would not rue the day as I do today.
|
||||
</blockquote>
|
||||
|
||||
次のように表示されます。
|
||||
|
||||
<blockquote>
|
||||
There I was, happy as a lark, skipping through the daisies, when I shyly handed my secret key to my one true love.
|
||||
|
||||
{% partial file="/docs/_snippets/secret-key-warning.md" /%}
|
||||
|
||||
Alas, if only I had heeded that sage advice, I would not rue the day as I do today.
|
||||
</blockquote>
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -17,15 +17,15 @@ labels:
|
||||
|
||||
| 名前 | 登場 | ステータス |
|
||||
|:----------------------------------|:-----------|:------------------------------------|
|
||||
| [fixAMMOverflowOffer][] | v2.1.1 | [投票中: 2024-03-27](https://xrpl.org/blog/2024/rippled-2.1.1.html "BADGE_80d0e0") |
|
||||
| [fixInnerObjTemplate][] | v2.1.0 | [投票中: 2024-02-20](https://xrpl.org/blog/2024/rippled-2.1.0.html "BADGE_80d0e0") |
|
||||
| [fixNFTokenReserve][] | v2.1.0 | [投票中: 2024-02-20](https://xrpl.org/blog/2024/rippled-2.1.0.html "BADGE_80d0e0") |
|
||||
| [fixAMMOverflowOffer][] | v2.1.1 | [有効: 2024-04-11](https://livenet.xrpl.org/transactions/64144409D991726D108B89D79F9305438D61928A322EF1CD14DC3A5F24CE64BC "BADGE_GREEN") |
|
||||
| [fixInnerObjTemplate][] | v2.1.0 | [有効: 2024-04-08](https://livenet.xrpl.org/transactions/EC67D9DF8D06067A76E8F8F43BC036B5E0267568F8D92624A658AC01A8186235 "BADGE_GREEN") |
|
||||
| [fixNFTokenReserve][] | v2.1.0 | [有効: 2024-04-12](https://livenet.xrpl.org/transactions/D708CF1799A27CB982F16FCE4762DD12738737A61E5850480BA51400280E06C4 "BADGE_GREEN") |
|
||||
| [DID][] | v2.0.0 | [投票中: 2024-01-09](https://xrpl.org/blog/2024/rippled-2.0.0.html "BADGE_80d0e0") |
|
||||
| [fixDisallowIncomingV1][] | v2.0.0 | [投票中: 2024-01-09](https://xrpl.org/blog/2024/rippled-2.0.0.html "BADGE_80d0e0") |
|
||||
| [fixFillOrKill][] | v2.0.0 | [投票中: 2024-01-09](https://xrpl.org/blog/2024/rippled-2.0.0.html "BADGE_80d0e0") |
|
||||
| [fixDisallowIncomingV1][] | v2.0.0 | [有効: 2024-04-11](https://livenet.xrpl.org/transactions/50286B4B9C95331A48D3AD517E1FD3299308C6B696C85E096A73A445E9EB1BFB "BADGE_GREEN") |
|
||||
| [fixFillOrKill][] | v2.0.0 | [有効: 2024-04-11](https://livenet.xrpl.org/transactions/3209D6B66D375C23EEBE7C3DD3058B361427148D80C570B8E791D4C76555FA7B "BADGE_GREEN") |
|
||||
| [XChainBridge][] | v2.0.0 | [投票中: 2024-01-09](https://xrpl.org/blog/2024/rippled-2.0.0.html "BADGE_80d0e0") |
|
||||
| [AMM][] | v1.12.0 | [有効: 2024-03-22](https://livenet.xrpl.org/transactions/75F52BB86416717288999523063D54E24290EFEA2E99DF78E80A12BD1C8FAC99 "BADGE_GREEN") |
|
||||
| [XRPFees][] | v1.10.0 | [投票中: 2023-03-14](https://xrpl.org/blog/2023/rippled-1.10.0.html "BADGE_80d0e0") |
|
||||
| [XRPFees][] | v1.10.0 | [有効: 2023-03-25](https://xrpl.org/blog/2023/rippled-1.10.0.html "BADGE_80d0e0") |
|
||||
| [Clawback][] | v1.12.0 | [有効: 2024-02-08](https://livenet.xrpl.org/transactions/C6BCCE60DFA4430A1F9097D774EA49E6FEFB1B535BA0EF9170DA0F2D08CDDB11 "BADGE_GREEN") |
|
||||
| [fixReducedOffersV1][] | v1.12.0 | [有効: 2023-11-24](https://livenet.xrpl.org/transactions/87723D9D01AFAD8E55C944D7D1598969A8FBD852FCACAE361A40CBF5D4CB3BB1 "BADGE_GREEN") |
|
||||
| [fixNFTokenRemint][] | v1.11.0 | [有効: 2023-11-27](https://livenet.xrpl.org/transactions/CA4562711E4679FE9317DD767871E90A404C7A8B84FAFD35EC2CF0231F1F6DAF "BADGE_GREEN") |
|
||||
@@ -112,110 +112,6 @@ labels:
|
||||
|
||||
## 既知のAmendmentsの詳細
|
||||
|
||||
### fixAMMOverflowOffer
|
||||
|
||||
[fixAMMOverflowOffer]: #fixammoverflowoffer
|
||||
|
||||
| Amendment | fixAMMOverflowOffer |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 12523DF04B553A0B1AD74F42DDB741DE8DC06A03FC089A0EF197E2A87F1D8107 |
|
||||
| ステータス | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | はい |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このAmendmentにより、決済エンジンにおけるAMMの大規模な合成オファーの不適切な処理が修正されます。このAmendmentは重大な修正であるため、ソースコードのデフォルトの投票はYESに設定されています。
|
||||
|
||||
### fixInnerObjTemplate
|
||||
|
||||
[fixInnerObjTemplate]: #fixinnerobjtemplate
|
||||
|
||||
| Amendment | fixInnerObjTemplate |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | C393B3AEEBF575E475F0C60D5E4241B2070CC4D0EB6C4846B1A07508FAEFC485 |
|
||||
| ステータス | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentにより、AMMの`sfVoteEntry`と`sfAuctionSlot`の内部オブジェクトの`sfTradingFee`フィールドと`sfDiscountedFee`フィールドにアクセスする際の問題が修正されました。
|
||||
|
||||
現在、内部オブジェクトのテンプレートはオブジェクトの生成時に設定されません。オブジェクトに`soeDEFAULT`フィールドがあり、初期値にデフォルト値が設定されている場合、そのフィールドにアクセスすると、状況によっては`tefEXCEPTION`エラーが発生します。このamendmentにより、内部オブジェクトテンプレートを設定するための追加の真偽値引数を含む`STObject`コンストラクタのオーバーロードが追加されます。
|
||||
|
||||
|
||||
### fixNFTokenReserve
|
||||
|
||||
[fixNFTokenReserve]: #fixnftokenreserve
|
||||
|
||||
| Amendment | fixNFTokenReserve |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 03BDC0099C4E14163ADA272C1B6F6FABB448CC3E51F522F978041E4B57D9158C |
|
||||
| ステータス | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentにより、`NFTokenAcceptOffer`トランザクタに`OwnerCount`が変更されたかどうかのチェックが追加されます。変更された場合、更新されたオブジェクト数に対して準備金要件が満たされているかどうかを追加でチェックします。
|
||||
|
||||
|
||||
### fixDisallowIncomingV1
|
||||
[fixDisallowIncomingV1]: #fixdisallowincomingv1
|
||||
|
||||
| Amendment | fixDisallowIncomingV1 |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 15D61F0C6DB6A2F86BCF96F1E2444FEC54E705923339EC175BD3E517C8B3FF91 |
|
||||
| ステータス | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentにより、ユーザが自分のアカウントで`lsfDisallowIncomingTrustline`フラグを有効にした後にトラストラインを承認する際の問題が修正されます。
|
||||
|
||||
この問題を再現するには
|
||||
|
||||
1. 発行者が自分のアカウントに`asfRequireAuth`を設定します。
|
||||
2. ユーザが自分のアカウントに`asfDisallowIncomingTrustline`を設定します。
|
||||
3. ユーザは`SetTrust`トランザクションを発行者に送信します。
|
||||
|
||||
4. 発行者はトラストラインを承認できません。
|
||||
|
||||
このamendmentにより、発行者はトラストラインを認可できるようになりました。
|
||||
|
||||
このamendmentは、[DisallowIncoming][] amendmentが有効でない場合、影響はありません。
|
||||
|
||||
|
||||
### fixFillOrKill
|
||||
[fixFillOrKill]: #fixfillorkill
|
||||
| Amendment | fixFillOrKill |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 3318EA0CF0755AF15DAC19F2B5C5BCBFF4B78BDD57609ACCAABE2C41309B051A |
|
||||
| ステータス | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentは`FlowCross`amendmentで導入された問題を修正します。`tfFillOrKill`フラグが設定され、`tfSell`フラグが設定されていないオファーは、オファーの取引レートがオーダーブックのレートよりも良いが、完全に一致しない場合に失敗します。
|
||||
|
||||
このamendmentにより、決済エンジンはこのシナリオを適切に処理できるようになり、オファーの交差が可能になります。
|
||||
|
||||
このamendmentは、[FlowCross][] amendmentが有効でない場合、影響はありません。
|
||||
|
||||
### DID
|
||||
[DID]: #did
|
||||
|
||||
| Amendment | DID |
|
||||
|:-------------|:----|
|
||||
| Amendment ID | DB432C3A09D9D5DFC7859F39AE5FF767ABC59AED0A9FB441E83B814D8946C109 |
|
||||
| ステータス | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
[World Wide Web Consortium](https://www.w3.org/press-releases/2022/did-rec/)標準に準拠した分散アイデンティティ(DID)機能を追加します。DIDは、中央集権的な機関に依存せず、DID主体によって管理されるデジタルIDを提供します。
|
||||
|
||||
次の新しいトランザクションを追加します。
|
||||
|
||||
- DIDDelete - XRPLアカウントに関連付けられたDIDを削除します。
|
||||
- DIDSet - 新しいDIDを作成するか、既存のDIDを更新します。
|
||||
|
||||
新しい`DID`レジャーエントリタイプを追加します。
|
||||
|
||||
いくつかの新しいトランザクション結果コードを追加します。
|
||||
|
||||
|
||||
### AMM
|
||||
[AMM]: #amm
|
||||
@@ -299,38 +195,6 @@ Clawbackはデフォルトでは無効になっています。Clawbackを使用
|
||||
この修正の詳細については、[Clawback](../docs/concepts/tokens/fungible-tokens/clawing-back-tokens.md)をご覧ください。
|
||||
|
||||
|
||||
### XChainBridge
|
||||
[XChainBridge]: #xchainbridge
|
||||
|
||||
| Amendment | XChainBridge |
|
||||
|:-------------|:-----------------|
|
||||
| Amendment ID | C98D98EE9616ACD36E81FDEB8D41D349BF5F1B41DD64A0ABC1FE9AA5EA267E9C |
|
||||
| Status | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
クロスチェーンブリッジを追加し、メインネットとサイドチェーンなどのネットワーク間でのデジタル資産の移動を可能にします。
|
||||
|
||||
次の新しいトランザクションを追加します
|
||||
|
||||
- XChainAccountCreateCommit - 発行チェーン上でトランザクションを提出するために、Witnessサーバ用の新しいアカウントを作成します。
|
||||
- XChainAddAccountCreateAttestation - Witnessサーバが使用するアカウントが作成されたことを証明します。
|
||||
- XChainAddClaimAttestation - ロックチェーンで資産がロックされた証明書を提出します。
|
||||
- XChainClaim - 送信先チェーンで資産を請求します。
|
||||
- XChainCommit - ロックチェーン上の資産をロックします。
|
||||
- XChainCreateBridge - Bridgeレジャーオブジェクトを作成します。
|
||||
- XChainCreateClaimID - クロスチェーン送金に使用される新しいクロスチェーン請求IDを作成します。
|
||||
- XChainModifyBridge - ブリッジのパラメータを変更します。
|
||||
|
||||
次の新しいレジャーエントリタイプを追加します
|
||||
|
||||
- Bridge - XRP Ledgerを別のブロックチェーンと接続する単一のクロスチェーンブリッジ。
|
||||
- XChainOwnedClaimID - 送信元チェーン上の資金をロックまたはバーンする送信元チェーン上のアカウントの情報を含むクロスチェーン送金の値(ID)。
|
||||
- XChainOwnedCreateAccountClaimID - クロスチェーン送金でアカウントを作成する際の証明書。
|
||||
|
||||
いくつかの新しいトランザクション結果コードを追加します。
|
||||
|
||||
|
||||
### CryptoConditions
|
||||
[CryptoConditions]: #cryptoconditions
|
||||
|
||||
@@ -344,6 +208,28 @@ Clawbackはデフォルトでは無効になっています。Clawbackを使用
|
||||
この修正は有効ですが、[SusPay](#suspay) Amendmentも有効でない限り、何の影響も及ぼしません。SusPayの修正は、[Escrow](#escrow)の修正に置き換えられたため、CryptoConditionsの修正は効力を持ちません。
|
||||
|
||||
|
||||
### DID
|
||||
[DID]: #did
|
||||
|
||||
| Amendment | DID |
|
||||
|:-------------|:----|
|
||||
| Amendment ID | DB432C3A09D9D5DFC7859F39AE5FF767ABC59AED0A9FB441E83B814D8946C109 |
|
||||
| ステータス | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
[World Wide Web Consortium](https://www.w3.org/press-releases/2022/did-rec/)標準に準拠した分散アイデンティティ(DID)機能を追加します。DIDは、中央集権的な機関に依存せず、DID主体によって管理されるデジタルIDを提供します。
|
||||
|
||||
次の新しいトランザクションを追加します。
|
||||
|
||||
- DIDDelete - XRPLアカウントに関連付けられたDIDを削除します。
|
||||
- DIDSet - 新しいDIDを作成するか、既存のDIDを更新します。
|
||||
|
||||
新しい`DID`レジャーエントリタイプを追加します。
|
||||
|
||||
いくつかの新しいトランザクション結果コードを追加します。
|
||||
|
||||
|
||||
## CryptoConditionsSuite
|
||||
[CryptoConditionsSuite]: #cryptoconditionssuite
|
||||
|
||||
@@ -724,6 +610,20 @@ fix1623 Amendmentは、固定金額の[CheckCashトランザクション][]（`A
|
||||
この修正が適用された場合、これらの支払いは、代わりに[結果コード`temBAD_PATH_LOOP`](../docs/references/protocol/transactions/transaction-results/tem-codes.md)で失敗します。
|
||||
|
||||
|
||||
### fixAMMOverflowOffer
|
||||
|
||||
[fixAMMOverflowOffer]: #fixammoverflowoffer
|
||||
|
||||
| Amendment | fixAMMOverflowOffer |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 12523DF04B553A0B1AD74F42DDB741DE8DC06A03FC089A0EF197E2A87F1D8107 |
|
||||
| ステータス | 有効 |
|
||||
| デフォルトの投票(最新の安定版) | はい |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このAmendmentにより、決済エンジンにおけるAMMの大規模な合成オファーの不適切な処理が修正されます。このAmendmentは重大な修正であるため、ソースコードのデフォルトの投票はYESに設定されています。
|
||||
|
||||
|
||||
### fixAmendmentMajorityCalc
|
||||
[fixAmendmentMajorityCalc]: #fixamendmentmajoritycalc
|
||||
|
||||
@@ -754,6 +654,63 @@ Checksトランザクションがアカウントのメタデータに影響を
|
||||
この修正を適用しない場合、Checksトランザクション（[CheckCreate][]、[CheckCash][]、および[CheckCancel][]）は送信者のアカウント履歴のみを更新します。この修正を適用した場合、これらのトランザクションは、送信アカウントにも受信アカウントにも影響します。この修正は、[Checks Amendment](#checks)も有効でないかぎり効果がありません。
|
||||
|
||||
|
||||
### fixDisallowIncomingV1
|
||||
[fixDisallowIncomingV1]: #fixdisallowincomingv1
|
||||
|
||||
| Amendment | fixDisallowIncomingV1 |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 15D61F0C6DB6A2F86BCF96F1E2444FEC54E705923339EC175BD3E517C8B3FF91 |
|
||||
| ステータス | 有効 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentにより、ユーザが自分のアカウントで`lsfDisallowIncomingTrustline`フラグを有効にした後にトラストラインを承認する際の問題が修正されます。
|
||||
|
||||
この問題を再現するには
|
||||
|
||||
1. 発行者が自分のアカウントに`asfRequireAuth`を設定します。
|
||||
2. ユーザが自分のアカウントに`asfDisallowIncomingTrustline`を設定します。
|
||||
3. ユーザは`SetTrust`トランザクションを発行者に送信します。
|
||||
|
||||
4. 発行者はトラストラインを承認できません。
|
||||
|
||||
このamendmentにより、発行者はトラストラインを認可できるようになりました。
|
||||
|
||||
このamendmentは、[DisallowIncoming][] amendmentが有効でない場合、影響はありません。
|
||||
|
||||
|
||||
### fixFillOrKill
|
||||
[fixFillOrKill]: #fixfillorkill
|
||||
| Amendment | fixFillOrKill |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 3318EA0CF0755AF15DAC19F2B5C5BCBFF4B78BDD57609ACCAABE2C41309B051A |
|
||||
| ステータス | 有効 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentは`FlowCross`amendmentで導入された問題を修正します。`tfFillOrKill`フラグが設定され、`tfSell`フラグが設定されていないオファーは、オファーの取引レートがオーダーブックのレートよりも良いが、完全に一致しない場合に失敗します。
|
||||
|
||||
このamendmentにより、決済エンジンはこのシナリオを適切に処理できるようになり、オファーの交差が可能になります。
|
||||
|
||||
このamendmentは、[FlowCross][] amendmentが有効でない場合、影響はありません。
|
||||
|
||||
|
||||
### fixInnerObjTemplate
|
||||
|
||||
[fixInnerObjTemplate]: #fixinnerobjtemplate
|
||||
|
||||
| Amendment | fixInnerObjTemplate |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | C393B3AEEBF575E475F0C60D5E4241B2070CC4D0EB6C4846B1A07508FAEFC485 |
|
||||
| ステータス | 有効 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentにより、AMMの`sfVoteEntry`と`sfAuctionSlot`の内部オブジェクトの`sfTradingFee`フィールドと`sfDiscountedFee`フィールドにアクセスする際の問題が修正されました。
|
||||
|
||||
現在、内部オブジェクトのテンプレートはオブジェクトの生成時に設定されません。オブジェクトに`soeDEFAULT`フィールドがあり、初期値にデフォルト値が設定されている場合、そのフィールドにアクセスすると、状況によっては`tefEXCEPTION`エラーが発生します。このamendmentにより、内部オブジェクトテンプレートを設定するための追加の真偽値引数を含む`STObject`コンストラクタのオーバーロードが追加されます。
|
||||
|
||||
|
||||
### fixMasterKeyAsRegularKey
|
||||
[fixMasterKeyAsRegularKey]: #fixmasterkeyasregularkey
|
||||
|
||||
@@ -819,6 +776,22 @@ Checksトランザクションがアカウントのメタデータに影響を
|
||||
|
||||
このamendmentにより、アカウント削除の制限も導入されます。アカウントは、`FirstNFTSequence` + `MintedNFTokens` + 256が現在のレジャーシーケンスより小さい場合にのみ削除できます（256はアカウント削除のヒューリスティックな制限として選択されたもので、アカウント削除制約にすでに存在します）。この制約がなければ、特定の条件下で同一のNFTが再ミントされる可能性があります。
|
||||
|
||||
**注意:** これは、トークンをミントするためにローカルでNFTokenIDを計算しているプロジェクトやツールにとっては **破壊的な変更** です。NFTokenIDを計算するコードがある場合は、新しい計算式に合わせて更新する必要があります。後方互換性を保ちながらこれを行う方法の例については、こちらをご覧ください。[JavaScriptでのよく知られたリファレンス実装](https://gist.github.com/N3TC4T/a20fb528931ed009ebdd708be4938748?permalink_comment_id=4738760#gistcomment-4738760).
|
||||
|
||||
|
||||
### fixNFTokenReserve
|
||||
|
||||
[fixNFTokenReserve]: #fixnftokenreserve
|
||||
|
||||
| Amendment | fixNFTokenReserve |
|
||||
|:-------------|:--------------|
|
||||
| Amendment ID | 03BDC0099C4E14163ADA272C1B6F6FABB448CC3E51F522F978041E4B57D9158C |
|
||||
| ステータス | 有効 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
このamendmentにより、`NFTokenAcceptOffer`トランザクタに`OwnerCount`が変更されたかどうかのチェックが追加されます。変更された場合、更新されたオブジェクト数に対して準備金要件が満たされているかどうかを追加でチェックします。
|
||||
|
||||
|
||||
### fixNonFungibleTokensV1_2
|
||||
[fixNonFungibleTokensV1_2]: #fixnonfungibletokensv1_2
|
||||
@@ -1372,6 +1345,38 @@ XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも
|
||||
この修正が適用されれば、[`tfSetfAuth`を有効にした](../docs/references/protocol/transactions/types/trustset.md#trustsetのフラグ)`TrustSet`トランザクションにおいて、`RippleState`ノードの他のすべての値をデフォルト状態にしたままでも、新しい[`RippleState`レジャーオブジェクト](../docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md)を作成できます。新しい`RippleState`ノードでは、トランザクションの送信者が低いノードと見なされるか高いノードと見なされるかに応じて、[`lsfLowAuth`フラグまたは`lsfHighAuth`フラグ](../docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)が有効になります。トランザクションの送信者は、[asfRequireAuthフラグを有効](../docs/references/protocol/transactions/types/accountset.md#accountsetのフラグ)にして[AccountSetトランザクション](../docs/references/protocol/transactions/types/accountset.md)を送信することで、事前に[`lsfRequireAuth`](../docs/references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)を有効にしておく必要があります。
|
||||
|
||||
|
||||
### XChainBridge
|
||||
[XChainBridge]: #xchainbridge
|
||||
|
||||
| Amendment | XChainBridge |
|
||||
|:-------------|:-----------------|
|
||||
| Amendment ID | C98D98EE9616ACD36E81FDEB8D41D349BF5F1B41DD64A0ABC1FE9AA5EA267E9C |
|
||||
| Status | 投票中 |
|
||||
| デフォルトの投票(最新の安定版) | いいえ |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
クロスチェーンブリッジを追加し、メインネットとサイドチェーンなどのネットワーク間でのデジタル資産の移動を可能にします。
|
||||
|
||||
次の新しいトランザクションを追加します
|
||||
|
||||
- XChainAccountCreateCommit - 発行チェーン上でトランザクションを提出するために、Witnessサーバ用の新しいアカウントを作成します。
|
||||
- XChainAddAccountCreateAttestation - Witnessサーバが使用するアカウントが作成されたことを証明します。
|
||||
- XChainAddClaimAttestation - ロックチェーンで資産がロックされた証明書を提出します。
|
||||
- XChainClaim - 送信先チェーンで資産を請求します。
|
||||
- XChainCommit - ロックチェーン上の資産をロックします。
|
||||
- XChainCreateBridge - Bridgeレジャーオブジェクトを作成します。
|
||||
- XChainCreateClaimID - クロスチェーン送金に使用される新しいクロスチェーン請求IDを作成します。
|
||||
- XChainModifyBridge - ブリッジのパラメータを変更します。
|
||||
|
||||
次の新しいレジャーエントリタイプを追加します
|
||||
|
||||
- Bridge - XRP Ledgerを別のブロックチェーンと接続する単一のクロスチェーンブリッジ。
|
||||
- XChainOwnedClaimID - 送信元チェーン上の資金をロックまたはバーンする送信元チェーン上のアカウントの情報を含むクロスチェーン送金の値(ID)。
|
||||
- XChainOwnedCreateAccountClaimID - クロスチェーン送金でアカウントを作成する際の証明書。
|
||||
|
||||
いくつかの新しいトランザクション結果コードを追加します。
|
||||
|
||||
|
||||
### XChainBridge
|
||||
[XChainBridge]: #xchainbridge
|
||||
|
||||
|
||||
@@ -1,3 +1,17 @@
|
||||
theme.page.previousButton: "前のページ"
|
||||
theme.page.nextButton: "次のページ"
|
||||
theme.page.lastUpdated.timeago: "最終更新: "
|
||||
theme.markdown.editPage.text: 編集
|
||||
theme.toc.header: 目次
|
||||
theme.search.label: ドキュメントの検索
|
||||
theme.search.navbar.label: 検索
|
||||
theme.search.recent: 直近の検索
|
||||
theme.search.keys.navigate: 選択
|
||||
theme.search.keys.select: 決定
|
||||
theme.search.keys.exit: 閉じる
|
||||
theme.feedback.settings.label: 参考になりましたか?
|
||||
theme.footer.copyrightText: © 2024 XRP Ledger. オープンソース.
|
||||
|
||||
theme.navbar.about: 概要
|
||||
theme.navbar.docs: ドキュメント
|
||||
theme.navbar.resources: リソース
|
||||
@@ -11,190 +25,93 @@ sidebar.docs.tutorials: チュートリアル
|
||||
sidebar.docs.references: リファレンス
|
||||
sidebars.resources: リソース
|
||||
sidebar.resources.codesamples: コードサンプル
|
||||
topnav.about.xrp-ledger: XRP Ledger
|
||||
topnav.about.xrpl-overview: XRPLの概要
|
||||
topnav.about.use-cases-featured-projects: ユースケースと注目プロジェクト
|
||||
topnav.about.history: 歴史
|
||||
topnav.about.xrp: XRP
|
||||
topnav.about.xrp-overview: XRPの概要
|
||||
topnav.about.sustainability: 持続可能性
|
||||
topnav.about.impact: 環境への影響
|
||||
topnav.about.about: 概要
|
||||
topnav.about.xrpl-foundation: XRPL財団
|
||||
topnav.about.faq: よくある質問
|
||||
topnav.about.privacy-policy: プライバシーポリシー
|
||||
topnav.docs.title: ドキュメント
|
||||
topnav.docs.description: XRPL技術に掘り下げて組み込めましょう。
|
||||
topnav.docs.description: XRP Ledgerの世界に飛び込み、開発を始めましょう。
|
||||
topnav.docs.article-types: コンテンツの種類
|
||||
topnav.docs.concepts: 基本概念
|
||||
topnav.docs.tutorials: チュートリアル
|
||||
topnav.docs.references: リファレンス
|
||||
topnav.docs.infrastructure: インフラ
|
||||
topnav.docs.use-cases: ユースケース
|
||||
topnav.docs.payments: 支払い
|
||||
topnav.docs.tokenization: トークン化
|
||||
topnav.docs.defi: DeFi(分散型金融)
|
||||
topnav.docs.get-started: はじめよう
|
||||
topnav.resources.development: 開発
|
||||
topnav.resources.code-samples: サンプルコード
|
||||
topnav.resources.dev-tools: 開発者ツール
|
||||
topnav.resources.xrpl-learning-portal: XRPL学習ポータル
|
||||
topnav.resources.xrpl-brand-kit: XRPLブランドキット
|
||||
topnav.resources.current-status: 現在のステータス
|
||||
topnav.resources.join-in: 参加しよう
|
||||
topnav.resources.explorer: エクスプローラ
|
||||
topnav.resources.known-amendments: 既知のAmendment
|
||||
topnav.resources.contribute-code: コードへの貢献
|
||||
topnav.resources.contribute-documentation: ドキュメントへの貢献
|
||||
topnav.community.title: コミュニティ
|
||||
topnav.community.description: 話題に加わろう。
|
||||
Open Source.: オープンソース
|
||||
Jump to top of page: ページの先頭へ
|
||||
Edit page: ページを編集
|
||||
Search: 検索
|
||||
Search site...: サイトを検索
|
||||
Search for articles, training, and code samples...: 記事、トレーニング、コードサンプルを検索...
|
||||
Become an XRP Ledger Campus Ambassador: XRP Ledgerキャンパスアンバサダーになる
|
||||
Join the Student Cohort: 学生コミュニティに参加
|
||||
XRPL Campus Ambassadors: XRPLキャンパスアンバサダー
|
||||
Current Students: 現役学生
|
||||
Why become an XRPL Campus Ambassador?: XRPLキャンパスアンバサダーになる理由
|
||||
Benefits: メリット
|
||||
Join a global cohort of students empowering others to build on the XRPL.: XRPLをベースに他の人に力を与える、世界的な学生グループに参加しましょう。
|
||||
Exclusive Opportunities: 特別な機会
|
||||
Education: 学習
|
||||
Tutorials and workshops from leading XRPL and blockchain developers: トップクラスのXRPLおよびブロックチェーン開発者によるチュートリアルとワークショップ
|
||||
Swag: グッズ
|
||||
New XRPL swag for Ambassadors and swag to share with other students: アンバサダー用の特別なXRPLグッズと他の学生と共有できるグッズ
|
||||
Mentorship: メンター
|
||||
Career Acceleration: キャリア促進
|
||||
Stipend: 奨学金
|
||||
Should You Apply?: 応募すべき？
|
||||
Eligibility for XRPL Campus Ambassadors: XRPLキャンパスアンバサダーの参加資格
|
||||
A Leader: リーダー
|
||||
Active: アクティブ
|
||||
Curious: 好奇心旺盛
|
||||
Eager to learn more about technical blockchain topics and the XRPL: 技術的なブロックチェーンのトピックやXRPLについてより深く学びたい
|
||||
Passionate: 情熱的
|
||||
Creative: クリエイティブ
|
||||
Ability to think outside the box to grow the XRPL student community: 既成概念にとらわれず、XRPLの学生コミュニティを成長させる思考力
|
||||
Process to become a Campus Ambassador: キャンパスアンバサダー就任までの流れ
|
||||
How it Works: 主な仕組み
|
||||
Apply now to become an XRPL Campus Ambassador.: XRPLキャンパスアンバサダーになりたい方は今すぐ応募しましょう。
|
||||
Apply: 応募
|
||||
Submit an application to be considered for the Campus Ambassador program.: キャンパスアンバサダープログラムの選考を受けるには、応募書類を提出してください。
|
||||
Interview: 面接
|
||||
Join: 参加
|
||||
Learn: 学習
|
||||
Apply for Fall 2023: 2023年秋の申し込み
|
||||
Join a global cohort of Student Ambassadors: 学生アンバサダーのグローバルなコミュニティに参加する
|
||||
Global Community: グローバルコミュニティ
|
||||
Stay connected to the XRPL Campus Ambassadors: XRPL キャンパスアンバサダーとの繋がりを持つ
|
||||
Connect: 繋がる
|
||||
MeetUp: ミートアップ
|
||||
Attend an XRPL Meetup in your local area: 地域のXRPLミートアップに参加しましょう。
|
||||
Dev.to Blog: Dev.to ブログ
|
||||
Read more about the activity of the XRPL Ambassadors: XRPLアンバサダーの活動についてもっと知る。
|
||||
Join the conversation on the XRPL Developer Discord: XRPL開発者Discordで意見交換しましょう。
|
||||
Start Building with Example Code: コードサンプルから開発を始める
|
||||
Code Samples: コードサンプル
|
||||
Browse sample code for building common use cases on the XRP Ledger: XRP Ledger上で一般的なユースケースを構築するためのコードサンプルを見ることができます
|
||||
Contribute Code Samples: コードサンプルへの貢献
|
||||
Help the XRPL community by submitting your<br> own code samples: コードサンプルを投稿して、XRPLコミュニティに貢献しましょう
|
||||
The XRPL Community: XRPL コミュニティ
|
||||
Find the community on the platforms below: 以下のプラットフォームでコミュニティにアクセスできます。
|
||||
Join the Conversation: 参加する
|
||||
Run an XRP Ledger network node: XRP Ledgerのネットワークノードを実行する
|
||||
Contribute to Consensus: コンセンサスへの貢献
|
||||
Apply for funding to build your XRPL project: 将来のXRPLプロジェクトのための資金調達に応募する
|
||||
Awarded in a single grant: 1回のGrantでの助成金
|
||||
Distributed to grant recipients: 助成対象者への配布
|
||||
Open-source projects funded : オープンソースプロジェクトへの資金提供
|
||||
Learn More: もっと知る
|
||||
Showcase your XRPL project, application or product: XRPLプロジェクト、アプリケーション、製品の紹介
|
||||
XRPL Community Spotlight: XRPL コミュニティの紹介
|
||||
Submit Your Projects: プロジェクトを登録する
|
||||
Read the Blog: ブログを読む
|
||||
Check out global events across the XRPL community: XRPLコミュニティで開催されるグローバルなイベントをチェック
|
||||
XRPL Events: XRPLイベント
|
||||
View All Events: 全てのイベントを見る
|
||||
Discover your next career opportunity in the XRPL community: XRPLコミュニティであなたの次のキャリアを見つけましょう
|
||||
Review guidelines for using XRPL design assets: XRPLのデザインアセットを使用するためのガイドラインを確認
|
||||
XRPL Assets: XRPLのアセット
|
||||
Download the PDF and Assets: PDFとアセットをダウンロード
|
||||
A community-driven resource for all things XRPL.org: XRPとXRP Ledgerのあらゆるものを提供する、コミュニティ主体のリソース
|
||||
Contribute to XRPL.org: XRPL.orgに貢献する
|
||||
Read Contributor Guidelines: コントリビュータガイドラインを読む
|
||||
Dev Tools: 開発者ツール
|
||||
Explorers: エクスプローラ
|
||||
API Access: APIアクセス
|
||||
Other: その他
|
||||
Have an Idea For a Tool?: ツールのアイデアをお持ちですか？
|
||||
Open a pull Request: プルリクエストを作成する
|
||||
Full documentation index: 全ドキュメントの目次
|
||||
See Everything: 全てを見る
|
||||
XRP Ledger Developer Resources: XRP Ledger 開発者向けリソース
|
||||
Documentation: XRP Ledger ドキュメント
|
||||
rippled API Reference: rippled APIリファレンス
|
||||
XRP Faucet: XRP Faucet
|
||||
Getting Started with Python: Pythonを使ってみよう
|
||||
Websocket API Tool: Websocket APIツール
|
||||
XRP Ledger Explorer: XRP Ledgerエクスプローラ
|
||||
Advanced Payment Features: 高度な支払い機能
|
||||
Governance and the Amendment Process: ガバナンスとAmendmentプロセス
|
||||
Federated Sidechains: 連合サイドチェーン
|
||||
On-Chain Finance: オンチェーン金融
|
||||
Trade on the decentralized exchange: 分散型取引所でトレード
|
||||
Make payments: 支払いを実行
|
||||
Use specialized payment types: 専門的な種類の支払いを行う
|
||||
Tokens: トークン
|
||||
Non-fungible Tokens: 非代替性トークン
|
||||
Issue a stablecoin: ステーブルコインを発行
|
||||
Assign an authorized minter: 認可Minterの割り当て
|
||||
Payments: ペイメント
|
||||
Peer to peer payments: 直接支払い
|
||||
Cross-currency payments: クロスカレンシー決済
|
||||
Escrows: エスクロー
|
||||
Intro to XRP Ledger: XRP Ledger クイックスタート
|
||||
Accounts: アカウント
|
||||
Decentralized Exchange: 分散型取引所
|
||||
Tokenization: Tokenization
|
||||
Faucets: XRP Faucet
|
||||
Get credentials and test-XRP for XRP Ledger Testnet or Devnet.: XRP Ledger TestnetまたはDevnetでアカウントとテスト用XRPを取得しましょう
|
||||
WebSocket Tool: Websocketツール
|
||||
Send sample requests and get responses from the rippled API.: サンプルリクエストを送信し、rippled APIからレスポンスを取得します。
|
||||
Transaction Sender: トランザクション送信ツール
|
||||
Concepts: コンセプト
|
||||
Read the Docs: ドキュメントを読む
|
||||
Tutorials: チュートリアル
|
||||
Get step-by-step guidance to perform common tasks with the XRP Ledger.: XRP Ledgerで一般的な作業の手順をご覧ください。
|
||||
View Tutorials: チュートリアルを見る
|
||||
References: リファレンス
|
||||
View References: リファレンスを見る
|
||||
Use Cases: ユースケース
|
||||
Getting Started: 始めましょう
|
||||
Quickstart to XRP Ledger: XRP Ledger クイックスタート
|
||||
An introduction to fundamental aspects of the XRP Ledger.: XRP Ledgerの基本的な機能の紹介
|
||||
Get Started: 始めましょう
|
||||
Watch Full Series: 全てのシリーズを見る
|
||||
Interact with the XRP Ledger in a language of your choice: お好みの言語でXRP Ledgerへアクセスできます
|
||||
Explore SDKs: SDKを探す
|
||||
Intermediate Learning Sources: 次の学習教材
|
||||
Explore, Test, Verify: 探索、テスト、検証
|
||||
Explore Dev Tools: 開発者ツールを探索
|
||||
Browse By Recommended Pages: おすすめのページを見る
|
||||
Get Free Test XRP: テスト用XRPを入手
|
||||
Generate Testnet Credentials: テストネットのアカウントを作成
|
||||
See full documentation index: 全ドキュメントの目次
|
||||
Find the XRPL Community Around the World: 世界中のXRPLコミュニティを見つけよう
|
||||
Events: イベント
|
||||
The XRPL Developer Summit: XRPL開発者サミット
|
||||
Save the Date: 日程を確認
|
||||
Upcoming Events: 今後のイベント情報
|
||||
Explore past community-hosted events: 過去のコミュニティ主催のイベントを見る
|
||||
Past Events: 過去のイベント
|
||||
Sorry, this page is not available in your language.: 申し訳ありませんが、このページはお使いの言語では提供されていません。
|
||||
XRPL Developer Funding Programs: XRPL開発者向け資金提供プログラム
|
||||
Project Resources: プロジェクト資金
|
||||
Explore funding opportunities for developers and teams: 開発者やチームのための資金調達の方法を見つけましょう
|
||||
Funding Overview: 資金調達の概要
|
||||
XRPL Hackathons: XRPLハッカソン
|
||||
Join an Event: イベントに参加
|
||||
See Upcoming Events: 今後のイベントを見る
|
||||
Best for: こんな方に最適
|
||||
Software developers and teams building directly on the XRP Ledger: XRP Ledger上のソフトウェア開発者やXRP Ledger上で直接開発を行うチーム
|
||||
Required: 必須要件
|
||||
Some coding experience: コーディング経験
|
||||
Level: レベル
|
||||
XRPL beginner to advanced developers: XRPLの初級開発者から上級開発者まで
|
||||
Funding Levels: 資金調達の規模
|
||||
Prize money and awards: 賞金および賞品
|
||||
Fund Your Project: プロジェクトの資金調達
|
||||
Past awardees include: 過去の受賞者は次の通り
|
||||
Visit XRPL Grants: XRPL Grantsを見る
|
||||
XRPL intermediate to advanced developers: XRPLの中級開発者から上級開発者
|
||||
$10,000 - $200,000: $10,000 ~ $200,000
|
||||
XRPL Accelerator: XRPLアクセラレータ
|
||||
Advance your project: プロジェクトの推進
|
||||
View XRPL Accelerator: XRPLアクセラレータを見る
|
||||
$50,000 (grant) + pitch for venture funding: $50,000(助成金)＋ベンチャー資金へのピッチ
|
||||
Provide a Better Alternative to Bitcoin: Bitcoinに代わる選択肢
|
||||
XRPL's Origin: XRPLの原点
|
||||
XRPL Launches its Native Currency, XRP: XRPL、ネイティブ通貨「XRP」がローンチ
|
||||
OpenCoin Rebranded to Ripple Labs: 2013年、OpenCoinからRipple Labsにブランド変更
|
||||
XRPL Foundation Launched: XRPL財団の創設
|
||||
The Blockchain<br class=\until-sm\/> Built for Business: ビジネスのための<br class=\until-sm\/>ブロックチェーン
|
||||
XRPL | XRP Ledger:
|
||||
Start Building: 始める
|
||||
|
||||
topnav.community.get-involved: 参加する
|
||||
topnav.community.events: イベント
|
||||
topnav.community.ambassadors: アンバサダー
|
||||
topnav.community.developer-funding: 開発者向け資金提供
|
||||
topnav.community.xrpl-jobs: XRPLの仕事
|
||||
topnav.community.dev-blog: 開発者ブログ
|
||||
topnav.community.xrpl-grants: XRPL Grants
|
||||
topnav.community.github: GitHub
|
||||
topnav.community.report-a-scam: 詐欺の報告
|
||||
footer.about.xrpl-overview: XRPLの概要
|
||||
footer.about.use-cases-projects: ユースケースとプロジェクト
|
||||
footer.about.history: 歴史
|
||||
footer.about.impact: 環境への影響
|
||||
footer.about.xrpl-foundation: XRPL財団
|
||||
footer.about.faq: よくある質問
|
||||
footer.about.privacy-policy: プライバシーポリシー
|
||||
footer.docs.xrpl-documentation: XRPLドキュメント
|
||||
footer.docs.introduction: はじめに
|
||||
footer.docs.use-cases: ユースケース
|
||||
footer.docs.concepts: 基本概念
|
||||
footer.docs.tutorials: チュートリアル
|
||||
footer.docs.references: リファレンス
|
||||
footer.docs.infrastructure: インフラ
|
||||
footer.resources.code-samples: サンプルコード
|
||||
footer.resources.dev-tools: 開発者ツール
|
||||
footer.resources.xrpl-learning-portal: XRPL学習ポータル
|
||||
footer.resources.xrpl-brand-kit: XRPLブランドキット
|
||||
footer.resources.explorer: エクスプローラ
|
||||
footer.resources.known-amendments: 既知のAmendment
|
||||
footer.resources.contribute-code: コードへの貢献
|
||||
footer.resources.contribute-documentation: ドキュメントへの貢献
|
||||
footer.community.community: コミュニティ
|
||||
footer.community.events: イベント
|
||||
footer.community.ambassadors: アンバサダー
|
||||
footer.community.developer-funding: 開発者向け資金提供
|
||||
footer.community.xrpl-jobs: XRPLの仕事
|
||||
footer.community.dev-blog: 開発者ブログ
|
||||
footer.community.xrpl-grants: XRPL Grants
|
||||
footer.community.github: GitHub
|
||||
footer.community.report-a-scam: 詐欺の報告
|
||||
|
||||
# index.page.tsx
|
||||
home.hero.h1part1: ビジネスのための
|
||||
home.hero.h1part2: ブロックチェーン
|
||||
XRPL | XRP Ledger: XRPL | XRP Ledger
|
||||
Start Building: 始めよう
|
||||
'The XRP Ledger: The Blockchain Built for Business': 'XRP Ledger: ビジネスに最適なブロックチェーン'
|
||||
The XRP Ledger (XRPL) is a decentralized, public blockchain led by a global community of businesses and developers looking to solve problems and create value.: XRP Ledger(XRPL)は課題の解決と価値の創造を目指す企業と開発者のグローバルコミュニティが主導する、分散型のパブリックブロックチェーンです。
|
||||
Proven reliable over more than a decade of error-free functioning, the XRPL offers streamlined development, low transaction costs, high performance, and sustainability. So you can build with confidence–and move your most critical projects forward.: 10年以上にわたって稼働し、高い信頼性が実証されているXRPLは、合理化された開発、低い取引コスト、高いパフォーマンス、そして持続可能性を提供します。これにより、我々は安心して開発し、プロジェクトに専念することができます。
|
||||
Why developers choose the XRP Ledger: 開発者がXRP Ledgerを選択する理由
|
||||
Public and Decentralized: パブリック＆分散型
|
||||
Open source, open to anyone to build on, maintained by the community: オープンソースで、誰でも構築でき、コミュニティによって維持されています
|
||||
@@ -204,45 +121,477 @@ High Performance: 高パフォーマンス
|
||||
Thousands of transactions settled in seconds: 数千件のトランザクションを数秒で決済することが可能です
|
||||
Low Cost: 低コスト
|
||||
Motivated Community: 活発なコミュニティ
|
||||
Companies, developers, validators, and users work together to make the XRP Ledger better every day: 開発者、バリデータ、ユーザ、そして企業によって、XRP Ledgerは日々進化しています
|
||||
Proven Reliability: 確かな信頼性
|
||||
10+ years of error-free, uninterrupted performance over more than 63 million ledgers: 10年以上、6,300万件以上のレジャーで安定したパフォーマンスを実現しています
|
||||
Powerful Features: パワフルな機能
|
||||
Activate the proven potential of the XRP Ledger and find a trusted foundation for your next innovation: XRP Ledgerを活用し、次のイノベーションのための信頼できるプラットフォームを見つけましょう。
|
||||
A high-performance decentralized peer-to-peer multi-currency exchange built directly into the blockchain: ブロックチェーンに直接組み込まれた高性能な分散型P2P多通貨取引所
|
||||
Cross-Currency Payments: クロスカレンシー決済
|
||||
Payment <br class='until-sm'/>Channels: ペイメント<br class='until-sm'/>チャネル
|
||||
Batched micropayments with unlimited speed, secured with XRP: XRPを利用した無制限のスピードでの小額決済が可能です
|
||||
Atomically settle multi-hop payments that cross currency or national boundaries with ease: 通貨や国境を越えたマルチホップ決済をアトミックに簡単に実現
|
||||
Payment Channels: ペイメントチャネル
|
||||
Batched micropayments with unlimited speed, secured with XRP: XRPによる安全かつ無制限のスピードでのバッチ式マイクロペイメント
|
||||
Multi-Signing: マルチシグ
|
||||
Flexible options for custody and security of on-ledger accounts: オンレジャーのアカウントの保護とセキュリティのための柔軟なオプションがあります
|
||||
Choose a path, and bring your project to life on the XRP Ledger: あなたのプロジェクトをXRP Ledger上でスタートさせましょう。
|
||||
Where to Start: 始めましょう
|
||||
Quickstart: クイックスタート
|
||||
Flexible options for custody and security of on-ledger accounts: オンレジャーアカウントの保護とセキュリティのための柔軟なオプション
|
||||
All currencies other than XRP can be represented in the XRP Ledger as tokens: XRP以外のすべての通貨は、XRP Ledger内でトークンとして表現されます
|
||||
Choose a path, and bring your project to life on the XRP Ledger: XRP Ledger上でプロジェクトをスタートしましょう。
|
||||
Where to Start: 最初の一歩
|
||||
Documentation: ドキュメント
|
||||
Access everything you need to get started working with the XRPL: XRPLを使うためのあらゆる情報にアクセスできます
|
||||
Guided Tutorials: ガイド付きチュートリアル
|
||||
Guided Tutorials: チュートリアルガイド
|
||||
Follow step-by-step guides for frequent tasks: ステップバイステップのガイドを使って頻出の作業をサポートします
|
||||
XRPL Fundamentals: XRPLの基礎知識
|
||||
Read about the XRPL’s foundational concepts: XRPLの基本概念について学びましょう
|
||||
Choose a Language: 開発言語の選択
|
||||
Get Inspired: インスピレーションを得る
|
||||
Find tools, documentation, and sample code in Python, Java, Javascript, or use HTTP APIs: Python、Java、Javascriptのツール、ドキュメント、サンプルコードを検索したり、HTTP APIを使用することができます
|
||||
Get Inspired: インスピレーション
|
||||
See what your peers have built on the XRPL: 他のユーザがXRPLで構築したものを見てみましょう
|
||||
Our Shared Vision for XRPL’s Future: XRPLの未来に対する私たちの共有のビジョン
|
||||
Together, we're building the greenest infrastructure to drive blockchain innovation that doesn't sacrifice utility or performance, to bring the developer community's vision to life.: 私たちは、開発者コミュニティのビジョンを実現するために、実用性や性能を犠牲にすることなく、ブロックチェーンのイノベーションを推進する最も環境に配慮したインフラストラクチャを共に構築しています
|
||||
Preview New Features: 新機能のプレビュー
|
||||
Explore what the community is building to enable new features and use cases on XRPL: コミュニティがどのような新機能やユースケースを構築しているのかを見てみましょう
|
||||
In Development: 開発中
|
||||
Smart Contracts: スマートコントラクト
|
||||
Open for Voting: 投票中
|
||||
Automated Market Makers: 自動マーケットメイカー
|
||||
Smart contracts to provide liquidity and earn passive income from facilitating currency exchange, complementary with the order-book DEX already built into the XRPL.: XRPLに組み込み済みのオーダーブックDEXと相互に補完する、流動性を提供し、通貨交換を促進することで受動的な収入を得るためのスマートコントラクト。
|
||||
Enabled: 利用可能
|
||||
Non-Fungible Tokens: 非代替性トークン
|
||||
Join the Community <br class=\until-sm\/> at XRPL.org: XRPL.orgの<br class=\until-sm\/>コミュニティに参加
|
||||
# Join the Community: XRPL.orgの
|
||||
# at XRPL.org: コミュニティに参加
|
||||
'Connect at XRPL.org, a community by and for the developers ': XRPL.orgは、XRPLを利用する開発者と
|
||||
' and entrepeneurs who rely on the XRPL.': 起業家のためのコミュニティです。
|
||||
Get Involved: 参加する
|
||||
Today’s Value, Tomorrow’s Vision: 現在の価値、将来のビジョン
|
||||
|
||||
# about/index.page.tsx
|
||||
about.index.h1part1: ビジネスに衝撃を
|
||||
about.index.h1part2: ' '
|
||||
XRPL Today, XRPL Tomorrow: 現在のXRPL、未来のXRPL
|
||||
How the XRP Ledger works: XRP Ledgerの仕組み
|
||||
XRP Ledger Basics: XRP Ledgerの基本
|
||||
The XRP Ledger is a decentralized public blockchain built for business.: XRP Ledgerは、エンタープライズレベルの分散型パブリックブロックチェーンです。
|
||||
The peer-to-peer network that manages the ledger is open to everyone. The XRP Ledger is maintained by software engineers, server operators, users, and businesses–a global community working to solve problems and create real-world value.: レジャーを管理するピアツーピアネットワークは誰でも利用できます。XRP Ledgerは、ソフトウェアエンジニア、サーバー運用者、ユーザ、そして企業によって維持されており、課題の解決と実世界での価値創造に取り組むグローバルなコミュニティです。
|
||||
Read Technical Docs: 技術ドキュメントを読む
|
||||
Watch Explainer Videos: 解説ビデオを見る
|
||||
How the Consensus Protocol works: コンセンサスプロトコルの仕組み
|
||||
Consensus: コンセンサス
|
||||
about.index.consensus.h5part1: パフォーマンスを維持するために、XRPLはコンセンサスプロトコルを使用しています。誰でも運用な特定の種類のサーバは
|
||||
about.index.consensus.h5part2: バリデータ
|
||||
about.index.consensus.h5part3: と呼ばれ3〜5秒ごとにトランザクションの順序と結果について合意します。
|
||||
All servers in the network process each transaction according to the same rules, and any transaction that follows the protocol is confirmed right away. All transactions are public, and strong cryptography guarantees the integrity of the system.: ネットワーク内のすべてのサーバは、同じルールに従って各トランザクションを処理し、プロトコルに従うすべてのトランザクションは即座に確認されます。すべてのトランザクションは公開され、強力な暗号化技術によってシステムの整合性が保証されます。
|
||||
about.index.consensus.ppart1: 現在120以上の
|
||||
about.index.consensus.ppart2: バリデータ
|
||||
about.index.consensus.ppart3: がXRP Ledgerのコンセンサスプロセスに参加しており、大学や取引所、企業、個人などにより運用されています。より多様な主体がバリデータを運用していくにつれて、コンセンサスプロトコルはブロックチェーンを長期的に分散化します。
|
||||
A Sustainable Blockchain: 持続可能なブロックチェーン
|
||||
Unlike most other blockchains, the XRP Ledger requires no mining and uses negligible energy, key to long-term growth and stability.: 他のいくつかのブロックチェーンとは異なり、XRP Ledgerはマイニングを必要とせず、長期的な成長と安定性の鍵となるエネルギー消費もごくわずかです。
|
||||
'Building with confidence on ': 実績と信頼性がある技術
|
||||
proven technology: ' '
|
||||
XRPL Today: XRPLの今
|
||||
With 10+ years of error-free functioning and enterprise companies as champions, XRPL has established reliability.: 10年以上にわたる安定した運用とエンタープライズ企業からの支持により、XRPLは信頼性を確立しています。
|
||||
With the XRPL, these developers are building innovative blockchain projects and applications across use cases including tokenization of assets, online gaming, asset custody, NFTs, and DeFi.: XRPLを使うことで、開発者は資産のトークン化やオンラインゲーム、カストディ、NFT、DeFiなどのユースケースにわたって革新的なブロックチェーンプロジェクトやアプリケーションを構築しています。
|
||||
Explore More: もっと知る
|
||||
Creating new value for long-term growth: 長期的な成長のための新たな価値を創造する
|
||||
XRPL Tomorrow: XRPLの未来
|
||||
As a community-led blockchain built for business, XRPL attracts companies and developers driven to solve real problems and generate real value–now and into the future.: ビジネスの発展のために構築されたコミュニティ主導のブロックチェーンであるXRPLは、現在そして将来にわたって真の問題を解決し、真の価値を生み出そうとする企業や開発者を惹きつけています。
|
||||
Significant investment in development, along with low transaction costs and energy usage, is fueling growth and opening up a wide variety of use cases at scale.: 低い取引コストとエネルギー使用量に加え、開発への多額の投資が成長を促し、大規模で多様なユースケースを開拓しています。
|
||||
Watch the explainer video series to learn more about the XRP Ledger: XRP Ledgerの詳細については、説明用のビデオシリーズをご覧ください。
|
||||
Tune In: 視聴する
|
||||
The Consensus Mechanism: コンセンサスの仕組み
|
||||
Nodes and Validators: ノードとバリデータ
|
||||
Sustainability of the XRP Ledger: XRP Ledgerの持続可能性
|
||||
Watch Full Series on YouTube: YouTubeで全シリーズを見る
|
||||
Tomorrow’s Blockchain Starts With You: 未来のブロックチェーンは、あなたから始まる
|
||||
about.index.tomorrow.ppart1: XRP Ledgerのイノベーションは、皆さんのような開発者によるコミュニティの経験を大切にしています。もしあなたが次の大きな
|
||||
about.index.tomorrow.ppart2: プロジェクト
|
||||
about.index.tomorrow.ppart3: を始める準備ができているなら、今すぐXRPLを試し、XRPL開発者向け資金提供プログラムへの応募を検討しましょう。
|
||||
Explore XRPL Developer Funding: XRPL開発者向け資金提供プログラムを見る
|
||||
Is XRPL a private blockchain, owned by Ripple?: XRPLはRipple社が所有するプライベートブロックチェーンですか？
|
||||
No, the XRP Ledger is a decentralized, public blockchain. Any changes that would impact transaction processing or consensus need to be approved by at least 80%% of the network. Ripple is a contributor to the network, but its rights are the same as those of other contributors. In terms of validation, there are 150+ validators on the network with 35+ on the Unique Node List (see “What are Unique Node Lists (UNLs)?” in the Full FAQ) — Ripple runs 1 of these nodes.: いいえ、XRP Ledgerは分散型のパブリックブロックチェーンです。取引処理やコンセンサスに影響を与えるような変更は、ネットワークの少なくとも80％の承認が必要です。Ripple社はネットワークへの貢献者ですが、その権利は他の貢献者と同じです。バリデーションの面では、ネットワーク上に150人以上のバリデータが存在し、35人以上がユニークノードリスト（FAQ全文の「ユニークノードリスト（UNL）とは何ですか」参照）に登録されており、Ripple社はこれらのノードのうち1つのみを管理しています。"
|
||||
Isn’t Proof of Work the best validation mechanism?: Proof of Workが最良のコンセンサスメカニズムではないでしょうか？
|
||||
Proof of Work (PoW) was the first mechanism to solve the double spend problem without requiring a trusted 3rd party. However the XRP Ledger’s consensus mechanism solves the same problem in a far faster, cheaper and more energy efficient way.: Proof of Work(PoW)は、信頼できる第三者を必要とせずに二重消費問題を解決する最初の仕組みでした。しかし、XRP Ledgerのコンセンサスメカニズムは、同じ問題をはるかに速く、安く、エネルギー効率の良い方法で解決しています。
|
||||
How can a blockchain be sustainable?: ブロックチェーンはどうして持続可能なのでしょうか？
|
||||
It’s been widely reported that Bitcoin’s energy consumption, as of 2021, is equivalent to that used by Argentina, with much of the electricity Bitcoin miners use coming from polluting sources. The XRP Ledger confirms transactions through a “consensus” mechanism - which does not waste energy like proof of work does - and leverages carbon offsets to be <a href='https://ripple.com/ripple-press/ripple-leads-sustainability-agenda-to-achieve-carbon-neutrality-by-2030/' target='_blank'>one of the first truly carbon neutral blockchains</a>.: ビットコインのエネルギー消費量は、2021年時点で、アルゼンチンが使用するエネルギーと同等であり、ビットコインの採掘者が使用する電力の多くは環境破壊につながる資源から供給されていると広く報告されています。XRP Ledgerは、Proof of Workのようにエネルギーを浪費しない「コンセンサス」メカニズムを通じてトランザクションを検証し、カーボンオフセットを活用して、<a href='https://ripple.com/ripple-press/ripple-leads-sustainability-agenda-to-achieve-carbon-neutrality-by-2030/' target='_blank'>最初の真のカーボンニュートラルなブロックチェーンの1つとなっています。</a>
|
||||
View Full FAQ: 全てのFAQを見る
|
||||
|
||||
# about/uses.page.tsx
|
||||
Powering Innovative Use Cases and Projects: 革新的なプロジェクトとユースケースを生み出す
|
||||
XRPL Ecosystem: XRPLエコシステム
|
||||
Explore Featured Projects: 注目プロジェクトを見る
|
||||
The XRPL has a rich ecosystem with many contributors globally. Explore the community of developers, validators, and partners.: XRPLには、世界中の多くの貢献者がいる豊かなエコシステムがあります。開発者、バリデータ、パートナーのコミュニティを見てみましょう。
|
||||
Introducing the XRPL Ecosystem: XRPLエコシステムの紹介
|
||||
about.uses.apps-build-1: XRPL上の
|
||||
about.uses.apps-build-2: アプリ,
|
||||
about.uses.apps-build-3: 取引所など
|
||||
Infrastructure: インフラ
|
||||
Build and operate components or systems that help the functionality of the XRP Ledger, such as Nodes, dev tools, storage, security and more.: ノード、開発ツール、ストレージ、セキュリティなど、XRP Ledgerの機能を助けるコンポーネントやシステムを構築・運用します。
|
||||
Developer Tooling: 開発者ツール
|
||||
Developers can leverage open-source libraries, SDKs and more to help build their project and access essential XRP Ledger functionality.: 開発者は、オープンソースライブラリやSDKなどを活用して、プロジェクトの構築や、XRP Ledgerの必須機能全般をサポートすることができます。
|
||||
Interoperability: 相互運用性
|
||||
Developers and node operators can build and run custom sidechains while leveraging the XRPL’s lean and efficient feature set.: 開発者やノード運用者は、XRPLの軽量で効率的な機能セットを活用しながら、カスタムサイドチェーンを構築・運用することができます。
|
||||
Wallet: ウォレット
|
||||
Build digital wallets to store passwords and interact with various blockchains to send and receive digital assets, including XRP.: パスワードを保存するデジタルウォレットを構築し、様々なブロックチェーンとやり取りして、XRPを含むデジタル資産を送受信します。
|
||||
NFTs: NFT
|
||||
XRPL supports the issuance of IOUs that represent a currency of any value, as well as non-fungible tokens (NFTs).: XRPLは、あらゆる価値の通貨を表すIOUのほか、非代替性トークン(NFT)にも対応しています
|
||||
Exchanges: 取引所
|
||||
Build sophisticated exchanges where users can invest and trade crypto and assets such as stocks, ETFs, and commodities.: ユーザが暗号資産や株式、ETF、コモディティなどの資産を投資・取引できる高度な取引所を構築します。
|
||||
Gaming: ゲーム
|
||||
The XRPL supports gaming at high speed given its reliable throughput, low fees, and sidechain interoperability.: 信頼性の高いスループット、低い手数料、サイドチェーンの相互運用性からXRPLは高速なゲームに最適です。
|
||||
Security: セキュリティ
|
||||
Build services and tools that help prevent and combat fraudulent activity with the XRPL.: XRPLを使った不正行為の防止や対策に役立つサービスやツールを構築します。
|
||||
Payments: ペイメント
|
||||
Leverage the efficiency and speed of the XRP Ledger to move value all over the globe.: 高効率かつ高速なXRP Ledgerを活用して、世界中で価値を移動させます。
|
||||
CBDC: CBDC
|
||||
A private version of the XRP Ledger provides Central Banks a secure, controlled, and flexible solution to issue and manage Central Bank Issued Digital Currencies (CBDCs).: XRP Ledgerのプライベートバージョンは、中央銀行が中央銀行発行デジタル通貨（CBDC）を発行・管理するための、安全で統制のとれた柔軟なソリューションを提供します。
|
||||
Sustainability: 持続可能性
|
||||
Use the XRP Ledger to tokenize carbon offsets as non-fungible tokens (NFTs).: XRP Ledgerを使用して、カーボンオフセットをNFT(Non-Fungible Token)としてトークン化します。
|
||||
Custody: カストディ
|
||||
Use the XRP Ledger to build crypto custody and securely hold, store and use your assets.: XRP Ledgerを使用して暗号資産カストディを構築し、資産を安全に保持、保管、使用することができます。
|
||||
Join the XRPL Ecosystem and showcase your XRPL project, application, or product. Get featured on the Developer Reflections blog or Ecosystem page.: XRPLエコシステムに参加して、あなたのXRPLプロジェクト、アプリケーション、製品を紹介しましょう。開発者向けブログやエコシステムのページで紹介されます。
|
||||
Submit Your Project: プロジェクトを登録
|
||||
about.uses.businesses.h3part1: XRP Ledgerを活用する
|
||||
about.uses.businesses.h3part2: プロジェクトと開発者
|
||||
Solving Real-World Problems: 実世界の問題の解決
|
||||
With intentional innovations, tools and documentation that accelerate development and minimize time to market, XRP Ledger is used to create solutions across an expansive range of industries and use cases.: XRP Ledgerは、開発を加速させ、市場投入までの時間を最短にするイノベーション、ツール、ドキュメントによって、幅広い業界やユースケースにおけるソリューションの構築に利用されています。
|
||||
Filter by Categories: カテゴリで絞り込む
|
||||
Featured Categories: 注目のカテゴリ
|
||||
Other Categories: 他のカテゴリ
|
||||
# TODO: Add projects' details
|
||||
|
||||
# about/history.page.tsx
|
||||
Provide a Better Alternative to Bitcoin: Bitcoinに代わる選択肢
|
||||
XRPL's Origin: XRPLの原点
|
||||
In 2011, three engineers—David Schwartz, Jed McCaleb, and Arthur Britto—began developing the XRP Ledger (XRPL). Fascinated by Bitcoin, they set out to create a better version that improved upon its limitations—with the goal of creating a digital asset that was more sustainable and built specifically for payments.: 2011年、David Schwartz、Jed McCaleb、Arthur Brittoの3人のエンジニアがXRP Ledger（XRPL）の開発を開始しました。Bitcoinに魅了されていた3人は、Bitcoinが持つ制約を改善したより優れたバージョンを作ることを目指し、さらに持続可能で決済に特化したデジタルアセットを構築するという目標を掲げました。
|
||||
The XRP Ledger first launched in June 2012. Shortly thereafter, they were joined by Chris Larsen, and the group started the Company NewCoin in September 2012 (quickly renamed OpenCoin and now named Ripple).: XRP Ledgerが初めてローンチされたのは2012年6月のことです。開発チームにはその後すぐにChris Larsenが加わり、2012年9月にOpenCoinという会社を創設しました（その後社名はOpenCoinに変わり、現在はRippleという名前になっています）。
|
||||
The XRPL founders gifted 80 billion XRP, the platform’s native currency, to the company. Ripple has since put the majority in escrow.: XRPLの創設者達は、このプラットフォームのネイティブ通貨である800億XRPを同社に贈与しました。その後、Ripple社はその大半をエスクローに預けています。
|
||||
XRP Ledger Development: XRP Ledgerの開発
|
||||
about.history.2011.part1: 2011年初頭、David Schwartz、Jed McCaleb、Arthur Brittの3人の開発者は、Bitcoinに魅了されながらも、Bitcoinに潜む問題を考えていました。彼らは、より持続可能な価値の送信システムを作ろうとしました。（このアイデアは、
|
||||
about.history.2011.part2: 2011年5月のフォーラムへの投稿「Bitcoin without mining」
|
||||
about.history.2011.part3: で概説されています）。
|
||||
Read More: 詳細を読む
|
||||
Their initial observations about the high energy consumption and scalability issues that would plague Bitcoin proved prescient. In 2019, estimates suggest Bitcoin mining used more energy than the entire country of Portugal. Moreover, their initial read indicated that significant problems could arise if any miner obtained (or miners colluded to obtain) greater than 50% of the mining power. That risk persists with Bitcoin (and Ethereum) today as mining power has consolidated in China.: 莫大なエネルギー消費量とスケーラビリティの問題が将来的にBitcoinを悩ませるだろうという最初の気付きには先見の明があったことが実証されました。（2019年には、Bitcoinのマイニングに使用されたエネルギー量はポルトガルの国全体のエネルギー消費量を上回ったと推定されています）。また、3人は当初から、もしいずれかのマイナー（または共謀したマイナー集団）がマイニングパワーの51%以上を獲得した場合、深刻な問題が発生するであろうと考えていました。Bitcoin（とEthereum）のマイニングパワーは中国に集中しているため、現在もなおそのリスクを抱えています。
|
||||
XRPL Launches its Native Currency, XRP: XRPL、ネイティブ通貨「XRP」がローンチ
|
||||
The trio of developers continued the work to build a distributed ledger that improved upon these fundamental limitations of Bitcoin, originally naming the code Ripple. The ledger included a digital asset that would originally be called “ripples” (XRP as the currency code) to follow the same naming convention as Bitcoin (BTC). At the time, the name Ripple stood for the open-source project, the unique consensus ledger (Ripple Consensus Ledger), transaction protocol (Ripple Transaction Protocol or RTXP), the network (Ripple network), and the digital asset (known as “ripples”).: 3人の開発者は、このようなBitcoinの基本的な限界を改善した分散型台帳を構築する作業を続け、当初そのコードを「Ripple」と命名しました。この台帳には、Bitcoin（BTC）と同じ命名規則に従って、当初は「ripples」（通貨コードとしてはXRP）と呼ばれるデジタル資産が含まれていました。当時、Rippleはオープンソースプロジェクト、独自のコンセンサスレジャー（Ripple Consensus Ledger）、トランザクションプロトコル（Ripple Transaction ProtocolまたはRTXP）、ネットワーク（Ripple network）、デジタルアセット（「ripples」と呼称）を表す名称でした。
|
||||
In practice, this approach led to many broad uses of “Ripple.” For clarity, the community simply started calling the digital asset by its currency code, “XRP.”: このアプローチでは「Ripple」という言葉が幅広い意味でよく使われるため、コミュニティでは明確にするためにデジタルアセットを「XRP」と呼び始めました。
|
||||
By June 2012, Schwartz, McCaleb, and Britto finished code development, and the Ledger was complete.: 2012年6月には、Schwartz、McCaleb、Brittoがコードの開発を完了し、XRP Ledgerが完全に機能するようになっていました。
|
||||
Once the XRP Ledger was live, 80% of the XRP was gifted to a new company that set out to build use cases for the digital asset—initially called NewCoin and renamed quickly to OpenCoin.: XRP Ledgerが完全に機能するようになると、XRPの80%が彼らによって設立された会社に贈与されました。当初その会社の名称はNewCoinでしたが、すぐにOpenCoinという名前に変更されました。
|
||||
Chris Larsen was the CEO of OpenCoin, and at the company's founding, Jed was co-founder and CTO, David Schwartz was the Chief Cryptography Officer, and Arthur Britto an advisor.: Chris LarsenがOpenCoinのCEOになり、創業時点では、Jed McCalebが共同創業者兼CTO、David Schwartzが最高暗号技術責任者、Arthur Brittoが相談役でした。
|
||||
OpenCoin Rebranded to Ripple Labs: OpenCoinからRipple Labsにブランド変更
|
||||
Since the early days, OpenCoin set out to revolutionize the global financial system. Despite the revolutionary ideals of many of Bitcoin’s early believers, Larsen never thought blockchain technology should be used to overthrow the existing financial system. He believed that history’s most transformative innovations have always relied on the great ideas that came before them—not displacing them.: OpenCoinはその初期から、世界の金融システムに革命を起こすことを目標としていました。Bitcoinの初期の賛同者の多くが革命的な理想を抱いていたにもかかわらず、Larsenはブロックチェーン技術が既存の金融システムを転覆させるために使用さわれるべきではないと考えていました。彼は、歴史上最も革新的なイノベーションは、常にその前に現れた偉大なアイデアに依存しており、それらを置き換えるものではないと信じていました。
|
||||
In early conversations with potential customers, the team was asked about the differences between the Ripple project and OpenCoin company. With the community starting to refer to the digital asset as XRP, company leaders decided to rebrand the company to Ripple Labs, which has been shortened over time to “Ripple.”: 創立して間もないころ、見込み顧客との商談のなかで、Rippleプロジェクトと会社であるOpenCoinとの違いについて尋ねられました。コミュニティではデジタルアセットを通貨コードである「XRP」と広く呼ぶようになっていたことから、経営陣は会社をRipple Labsというブランドに変更することを決めました。それが次第に短縮して「Ripple」と呼ばれるようになりました。
|
||||
Today, Ripple has created a use case leveraging the XRP Ledger and XRP for liquidity management in its cross-border payments business. Ripple also remains a stakeholder and contributor to the broader XRPL community.: 現在、この会社は自社の国際送金事業でXRPとXRP Ledgerを流動性管理に使用しています。Ripple社は今でも、広範なXRPLコミュニティのステークホルダーでありコントリビューターです。
|
||||
XRPL Foundation Launched: XRPL財団の創設
|
||||
about.history.xrplf.part1: 2020年9月24日に
|
||||
about.history.xrplf.part2: 設立
|
||||
about.history.xrplf.part3: されたXRPL財団は、分散化されたXRP Ledgerの開発と採用を加速させることをミッションとする独立した非営利団体です。財団は、XRP Ledgerを構築する開発者やその他の
|
||||
about.history.xrplf.part4: グローバルなコミュニティメンバー
|
||||
about.history.xrplf.part5: の増加に対応するための財団の活動資金として、Coil、Ripple、Gatehubから650万ドルを超える初期寄付金の提供を受けています。
|
||||
|
||||
# about/impact.page.tsx
|
||||
Today’s Value, Tomorrow’s Vision: 現在の価値、将来のビジョン
|
||||
Building for the Future: 未来を見据えた開発
|
||||
Consensus protocol is efficient and sustainable: 効率的で持続可能なコンセンサスプロトコル
|
||||
For more than 272 million migrants worldwide, sending and receiving money across borders is expensive, unreliable and complex.: 世界で2億7,200万人を超える移民にとって、国境を越えた送金は高額で不確実かつ複雑です。
|
||||
about.impact.feature.ppart1: オープンで分散型のブロックチェーンと暗号資産は、リテールや機関投資家からCBDC、NFT、クロスボーダー決済などの
|
||||
about.impact.feature.ppart2: 商業ユースケース
|
||||
about.impact.feature.ppart3: まで、金融サービス業界全体で導入が進んでいます。
|
||||
A Sustainable Future: 持続可能な未来
|
||||
What makes the XRPL sustainable?: XRPLが持続可能な理由は？
|
||||
XRPL’s unique consensus mechanism is eco-friendly—it does not require mining to settle transactions. This results in efficiency without sacrificing security, decentralization, or scalability.: XRPLの独自のコンセンサスメカニズムは環境に優しく、トランザクションを処理するためにマイニングを必要としません。このため、セキュリティ、分散性、スケーラビリティを犠牲にすることなく、効率化を実現することができます。
|
||||
The trivial amount of energy it does consume is then neutralized with carbon credits through EW Zero, an open-source blockchain decarbonization tool.: そして、消費するわずかなエネルギーは、オープンソースのブロックチェーンによる脱炭素ツール「EW Zero」を通じて、カーボンクレジットで相殺されます。
|
||||
Featured companies & projects running on the XRP Ledger.: XRP Ledgerで活動する注目の企業とプロジェクト
|
||||
Sustainable Projects: 持続可能なプロジェクト
|
||||
Learn more about companies and developers who are using the XRP Ledger to solve interesting problems efficiently and sustainably.: XRP Ledgerを利用して興味深い問題を効率的かつ持続的に解決している企業や開発者について、詳しくご紹介します。
|
||||
See More: 利用例を見る
|
||||
How can businesses and developers connect and contribute?: 開発者はどのように繋がり、貢献できるのでしょうか？
|
||||
"If you want to advance business with sustainable solutions to real-world problems, you’re invited to join the global, growing XRPL community. Here are some ways to get involved:": 現実世界の問題に対する持続可能なソリューションでビジネスを発展させたいと考える方は、グローバルに成長するXRPLコミュニティに参加しましょう。
|
||||
Join the Community: コミュニティに参加
|
||||
Blog: ブログ
|
||||
about.impact.blog.ppart1: " "
|
||||
about.impact.blog.ppart2: XRPL開発者ブログ
|
||||
about.impact.blog.ppart3: をチェックして、XRPLコミュニティのイノベーションと開発について最新情報を入手しましょう。
|
||||
Events: イベント
|
||||
about.impact.events.ppart1: " "
|
||||
about.impact.events.ppart2: ミートアップ、ハッカソン、カンファレンス
|
||||
about.impact.events.ppart3: に参加して、コミュニティの他のメンバーと交流しましょう。
|
||||
Code: コード
|
||||
about.impact.code.ppart1: " "
|
||||
about.impact.code.ppart2: Githubリポジトリ
|
||||
about.impact.code.ppart3: からブロックチェーンプロジェクトを見つけ、どのように貢献できるか見てみましょう。
|
||||
Connect: 繋がる
|
||||
about.impact.connect.ppart1: SNSで#XRPLCommunityを使って話題に加わりましょう。
|
||||
|
||||
# docs/index.page.tsx
|
||||
XRP Ledger Developer Resources: XRP Ledger 開発者向けリソース
|
||||
Concepts: コンセプト
|
||||
'Learn the "what" and the "why" behind fundamental aspects of the XRP Ledger.': XRP Ledgerの基本的な機能の背景を学びましょう。
|
||||
Read the Docs: ドキュメントを読む
|
||||
Tutorials: チュートリアル
|
||||
Get step-by-step guidance to perform common tasks with the XRP Ledger.: XRP Ledgerで頻出するタスクのガイドラインをご覧ください。
|
||||
View Tutorials: チュートリアルを見る
|
||||
References: リファレンス
|
||||
Look up reference documentation for the XRP Ledger protocol, API methods, and more.: XRP LedgerプロトコルやAPIメソッドなどのリファレンスドキュメントをご覧ください。
|
||||
View References: リファレンスを見る
|
||||
Use Cases: ユースケース
|
||||
On-Chain Finance: オンチェーン金融
|
||||
Algorithmic Trading: アルゴリズム取引
|
||||
List XRP as an Exchange: 取引所へのXRPのリスト
|
||||
Payment Types: 多様なPayment
|
||||
Tokens: トークン
|
||||
Stablecoin Issuer: ステーブルコインの発行者
|
||||
NFT Marketplace: NFTマーケットプレイス
|
||||
Digital Artist: デジタルアーティスト
|
||||
Peer-to-Peer Payments: 個人間の直接決済
|
||||
Cross-currency payments: クロスカレンシー決済
|
||||
Getting Started: 始めましょう
|
||||
Introduction to the XRP Ledger: XRP Ledgerのご紹介
|
||||
An introduction to fundamental aspects of the XRP Ledger.: XRP Ledgerの基本的な機能の紹介
|
||||
Introduction: XRP Ledgerの基本
|
||||
Intro to XRP Ledger: XRP Ledger クイックスタート
|
||||
Accounts: アカウント
|
||||
Decentralized Exchange: 分散型取引所
|
||||
Tokenization: トークン化
|
||||
Watch Full Series: 全てのシリーズを見る
|
||||
Interact with the XRP Ledger in a language of your choice: お好みの言語でXRP Ledgerへアクセスできます
|
||||
Explore SDKs: SDKを探す
|
||||
Intermediate Learning Sources: 次の学習教材
|
||||
Advanced Payment Features: 高度な支払い機能
|
||||
Governance and the Amendment Process: ガバナンスとAmendmentプロセス
|
||||
Federated Sidechains: 連合サイドチェーン
|
||||
Explore, Test, Verify: 探索、テスト、検証
|
||||
Explore Dev Tools: 開発者ツールを探す
|
||||
Use these web-based tools to assist during all stages of development, from getting your first payment to testing your implementation for best practices.: 次のWebベースのツールを使用して、最初の支払いからベストプラクティスのための実装テストまで、開発のすべてのステージにわたりサポートします。
|
||||
Faucets: XRP Faucet
|
||||
Get credentials and test-XRP for XRP Ledger Testnet or Devnet.: XRP Ledger TestnetまたはDevnetでアカウントとテスト用XRPを取得しましょう。
|
||||
WebSocket Tool: Websocketツール
|
||||
Send sample requests and get responses from the rippled API.: サンプルリクエストを送信し、rippled APIからレスポンスを取得しましょう。
|
||||
XRP Ledger Explorer: XRP Ledgerエクスプローラ
|
||||
View validations of new ledger versions in real-time, chart the location of servers in the XRP Ledger.: 新しいレジャーバージョンの検証結果をリアルタイムで表示したり、XRP Ledgerサーバの位置をチャートで表示します。
|
||||
Transaction Sender: トランザクション送信ツール
|
||||
Test how your code handles various XRP Ledger transactions by sending them over the Testnet to the address.: コードが様々なXRP Ledgerのトランザクションをどのように処理するか、テストネットを通じてテストしましょう。
|
||||
View All tools: 全てのツールを見る
|
||||
Browse By Recommended Pages: おすすめのページを見る
|
||||
Public API Methods: 公開APIメソッド
|
||||
Run a Validator: バリデータを運用
|
||||
Reserves: 準備金
|
||||
Transaction Types: トランザクションの種類
|
||||
Get Free Test XRP: テスト用XRPを入手
|
||||
Generate Testnet Credentials: テストネットのアカウントを作成
|
||||
Connect to the XRP Ledger Testnet network to develop and test your apps built on the XRP Ledger, without risking real money or impacting production XRP Ledger users.: XRP Ledger Testnetに接続することで、現実の資産やMainnetユーザに影響を与えることなくXRP Ledger上に構築するアプリを開発・テストすることができます。
|
||||
|
||||
# community/index.page.tsx
|
||||
XRPL Community: XRPLコミュニティ
|
||||
community.index.h1part1: 開発者とイノベーターによる
|
||||
community.index.h1part2: グローバルな
|
||||
community.index.h1part3: " "
|
||||
community.index.h1part4: ブロックチェーンコミュニティ
|
||||
Join the Conversation: 参加する
|
||||
Hot Topics Happening Now: 今話題のトピック
|
||||
community.index.event.h4part1: XRPLコミュニティ主催の
|
||||
community.index.event.h4part2: グローバルイベントをチェック
|
||||
Meet the XRPL community at meetups, hackathons, blockchain conferences, and more across global regions.: グローバルな地域で開催されるミートアップ、ハッカソン、ブロックチェーンカンファレンスなどで、XRPLコミュニティと出会いましょう。
|
||||
View All Events: 全てのイベントを見る
|
||||
UPCOMING EVENT: 次のイベント
|
||||
days: 日後
|
||||
# TODO: translate "XRPL Events Carousel Section"
|
||||
Get Funding: 資金を獲得
|
||||
funding been awarded: 受賞総額
|
||||
teams awarded globally: 受賞チーム数
|
||||
countries represented: 参加国数
|
||||
XRPL Developer Funding: XRPL開発者向けの資金提供
|
||||
Funding Opportunities for Blockchain Businesses: ブロックチェーンビジネスのための資金獲得の機会
|
||||
If you're a software developer or team looking to build your next blockchain business on the XRP Ledger (XRPL), numerous funding opportunities like grants and hackathons await your innovation.: あなたがXRP Ledger(XRPL)上で次のブロックチェーンビジネスを構築しようとしているソフトウェア開発者やチームであれば、助成金やハッカソンなど数多くの資金調達の機会があなたをお待ちしています。
|
||||
XRPL Community Spotlight: XRPLコミュニティの紹介
|
||||
Showcase your blockchain project, application, or product: あなたのブロックチェーンプロジェクト、アプリケーション、製品を紹介しましょう
|
||||
Get featured on the Developer Reflections blog or Ecosystem page, and amplify your innovation within the blockchain community.: 開発者向けブログやエコシステムのページで紹介され、ブロックチェーンコミュニティ内でのイノベーションを広めましょう。
|
||||
Submit Your Projects: プロジェクトを登録
|
||||
# TODO: translate project-cards
|
||||
View Projects: プロジェクトを見る
|
||||
Contribute to Consensus: コンセンサスへの貢献
|
||||
Run an XRP Ledger network node: XRP Ledgerのノードを実行する
|
||||
Thank you for your interest in contributing to XRP Ledger.: XRP Ledgerへの貢献に興味がありますか？
|
||||
Networks and Servers: ネットワークとサーバ
|
||||
Join UNL: UNLに参加
|
||||
Install & Configure: インストールと設定
|
||||
Troubleshooting: トラブルシューティング
|
||||
XRPL Careers: XRPLキャリア
|
||||
Discover your next career opportunity in the XRPL community: XRPLコミュニティで次のキャリアを見つけましょう
|
||||
Teams across the XRPL community are looking for talented individuals to help build their next innovation.: XRPLコミュニティ全体が、次のイノベーションを構築するために才能ある人物を探しています。
|
||||
View Open Roles: 募集中の職種を見る
|
||||
Contribute to XRPL.org: XRPL.orgに貢献する
|
||||
A Community-Driven Resource for All Things XRP Ledger: XRP Ledgerに関する情報を提供するコミュニティ主導のリソース
|
||||
Contribute to XRPL.org, the go-to resource for XRP Ledger. This open-source portal welcomes contributions from anyone for suggested changes.: XRP LedgerのためのリソースであるXRPL.orgに貢献しましょう。このオープンソースポータルでは、皆様からの変更や提案を歓迎します。
|
||||
Read Contributor Guidelines: ガイドラインを読む
|
||||
|
||||
# community/events.page.tsx
|
||||
Find the XRPL Community Around the World: 世界中のXRPLコミュニティを見つけよう
|
||||
# TODO: translate event details
|
||||
Register Now: いますぐ登録
|
||||
Check out meetups, hackathons, and other events hosted by the XRPL Community: XRPLコミュニティが主催するミートアップ、ハッカソン、その他のイベントをチェックしましょう
|
||||
"Filter By:": "絞り込み:"
|
||||
Conference: カンファレンス
|
||||
Meetups: ミートアップ
|
||||
Hackathons: ハッカソン
|
||||
AMAs: AMA
|
||||
Community Calls: コミュニティコール
|
||||
XRPL Zone: XRPL Zone
|
||||
Info Session: セッション
|
||||
# TODO: translate feature events
|
||||
Explore past community-hosted events: 過去のコミュニティ主催のイベントを見る
|
||||
Past Events: 過去のイベント
|
||||
# TODO: translate past events
|
||||
|
||||
# community/ambassadors.page.tsx
|
||||
Become an XRP Ledger Campus Ambassador: XRP Ledgerキャンパスアンバサダーになる
|
||||
Join the Student Cohort: 学生コミュニティに参加
|
||||
The XRPL Campus Ambassador program engages, supports, connects, and recognizes a group of student champions of the XRPL and empowers them to further advance engagement on the ledger.: XRPLキャンパスアンバサダープログラムは、XRPLの学生による代表者を参加させ、支援し、繋いで、表彰し、彼らがコミュニティ/エコシステムへの関与をさらに進めるように支援するものです。
|
||||
# Apply for Fall 2023: 2023年秋の申し込み #old
|
||||
XRPL Campus Ambassadors: XRPLキャンパスアンバサダー
|
||||
Current Students: 現役学生
|
||||
The XRPL Campus Ambassador program aims to elevate the impact of college students who are passionate about blockchain technology. In their role, Campus Ambassadors help educate other students about crypto and how to start building on the XRPL.: XRPLキャンパスアンバサダープログラムは、ブロックチェーン技術に情熱を持つ大学生の影響力を高めることを目指しています。彼らの役割として、キャンパスアンバサダーは他の学生に暗号通貨について教育し、XRPL上での開発を始める方法を教えます。
|
||||
Why become an XRPL Campus Ambassador?: XRPLキャンパスアンバサダーになる理由
|
||||
Benefits: メリット
|
||||
Join a global cohort of students empowering others to build on the XRPL.: XRPLをベースに他の人に力を与える、世界的な学生グループに参加しましょう
|
||||
Exclusive Opportunities: 特別な機会
|
||||
Get access and invitations to Ambassador-only events, conferences, and opportunities: アンバサダー限定のイベント、カンファレンス、チャンスの情報を入手できます
|
||||
Education: 学習
|
||||
Tutorials and workshops from leading XRPL and blockchain developers: トップクラスのXRPLおよびブロックチェーン開発者によるチュートリアルとワークショップを提供します
|
||||
Swag: グッズ
|
||||
New XRPL swag for Ambassadors and swag to share with other students: アンバサダー用の特別なXRPLグッズと他の学生と共有できるグッズを提供します
|
||||
Mentorship: メンター
|
||||
Serve as an advocate and receive support from notable members of the community: アドボケートの役割を果たし、コミュニティの主要メンバーからのサポートが提供されます
|
||||
Career Acceleration: キャリア促進
|
||||
Gain hands-on experience building communities and grow your professional network in the blockchain industry: ブロックチェーン業界におけるコミュニティ構築の経験を積み、プロフェッショナルなネットワークを広げることができます
|
||||
Stipend: 奨学金
|
||||
Receive a stipend to fund your ideas and initiatives that fuel XRPL growth on your campus: キャンパスでのXRPLの成長を促進するアイデアやイニシアチブの資金となる奨学金を受け取ることができます
|
||||
Should You Apply?: 応募すべきでしょうか？
|
||||
Eligibility for XRPL Campus Ambassadors: XRPLキャンパスアンバサダーの応募資格
|
||||
Students currently enrolled in an undergraduate or postgraduate program at an accredited college or university are eligible to apply.: 現在、認定された大学の学部または大学院に在籍している学生が応募可能です。
|
||||
A Leader: リーダー
|
||||
Interested in leading meetups and workshops for your local campus community: 学内のコミュニティでミートアップやワークショップを開催することに関心を持っている
|
||||
Active: アクティブ
|
||||
An active participant in the XRPL community or interested in blockchain and crypto technologies: XRPLコミュニティに積極的に参加している、またはブロックチェーンや暗号技術に興味を持っている
|
||||
Curious: 好奇心旺盛
|
||||
Eager to learn more about technical blockchain topics and the XRPL: ブロックチェーン技術やXRPLについてより深く学ぶ意欲がある
|
||||
Passionate: 情熱的
|
||||
Passionate about increasing XRPL education and awareness through events, content, and classroom engagement: イベント、コンテンツ、授業への参加を通じて、XRPLの教育と認知度を高めることに情熱を持っている
|
||||
Creative: クリエイティブ
|
||||
Ability to think outside the box to grow the XRPL student community: 既成概念にとらわれず、XRPLの学生コミュニティを成長させる思考力がある
|
||||
Process to become a Campus Ambassador: キャンパスアンバサダー就任までの流れ
|
||||
How it Works: 手続き
|
||||
Apply now to become an XRPL Campus Ambassador.: XRPLキャンパスアンバサダーになりたい方は今すぐ応募しましょう。
|
||||
Apply: 応募
|
||||
Submit an application to be considered for the Campus Ambassador program.: キャンパスアンバサダープログラムの選考を受けるには、応募書類を提出してください。
|
||||
Interview: 面接
|
||||
Tell the XRPL community-led panel more about yourself and your interest in the program during an interview.: XRPLコミュニティが中心となって運営する委員との面接で、あなた自身、またプログラムへの関心について詳しく話してください。
|
||||
Join: 参加
|
||||
Congrats on your new role! Join the global cohort of Ambassadors and meet with community participants during onboarding.: 就任おめでとうございます！グローバルなアンバサダーグループに参加し、新しいコミュニティメンバーとお会いしましょう。
|
||||
Learn: 学習
|
||||
Participate in personalized learning and training sessions for Ambassadors on the XRPL and blockchain technology.: XRPLおよびブロックチェーン技術に関するアンバサダー向けの個別学習およびトレーニングセッションへ参加しましょう。
|
||||
Join a global cohort of Student Ambassadors: 学生アンバサダーのグローバルなコミュニティに参加する
|
||||
Global Community: グローバルコミュニティ
|
||||
Stay connected to the XRPL Campus Ambassadors: XRPLキャンパスアンバサダーとの繋がりを持つ
|
||||
"To stay up-to-date on the latest activity, meetups, and events of the XRPL Campus Ambassadors be sure to follow these channels:": XRPL キャンパスアンバサダーの最新の活動、ミートアップ、イベントに関する最新情報を得るには、次のチャンネルをフォローしましょう。
|
||||
MeetUp: ミートアップ
|
||||
Attend an XRPL Meetup in your local area: 近隣のXRPLミートアップに参加しましょう
|
||||
Dev.to Blog: Dev.to ブログ
|
||||
Read more about the activity of the XRPL Ambassadors: XRPLアンバサダーの活動についてもっと知る
|
||||
Join the conversation on the XRPL Developer Discord: XRPL開発者Discordで意見交換しましょう
|
||||
|
||||
# community/developer-funding.tsx
|
||||
XRPL Developer Funding Programs: XRPL開発者向け資金提供プログラム
|
||||
Project Resources: プロジェクト資金
|
||||
Explore funding opportunities for developers and teams: 開発者やチームのための資金調達の方法を見つけましょう
|
||||
Funding Overview: 資金調達の概要
|
||||
"If you’re a software developer or team looking to build your next project or venture on the XRP Ledger (XRPL), there are a number of opportunities to fund your next innovation.": "XRP Ledger(XRPL)上に次のプロジェクトやベンチャーを構築しようとしているソフトウェア開発者やチーム向けの資金を提供されるチャンスは数多く存在します。"
|
||||
XRPL Hackathons: XRPLハッカソン
|
||||
Join an Event: イベントに参加
|
||||
Hackathons are open to all developers to explore and invent a project on the XRP Ledger. Visit the events page for updates on upcoming hackathons.: XRP Ledgerのハッカソンはプロジェクトを調査・考案するために、すべての開発者に開放されています。今後のハッカソンに関する最新情報は、イベントページでご確認ください。
|
||||
See Upcoming Events: 今後のイベントを見る
|
||||
Best for: こんな方に最適
|
||||
Software developers and teams building directly on the XRP Ledger: XRP Ledger上のソフトウェア開発者やXRP Ledger上で直接開発を行うチーム
|
||||
Required: 必須要件
|
||||
Some coding experience: コーディング経験
|
||||
Level: レベル
|
||||
XRPL beginner to advanced developers: XRPLの初級開発者から上級開発者まで
|
||||
Funding Levels: 資金調達の規模
|
||||
Prize money and awards: 賞金および賞品
|
||||
XRPL Grants: XRPL Grants
|
||||
Fund Your Project: プロジェクトの資金調達
|
||||
Developer grants for projects that contribute to the growing XRP Ledger community.: 成長するXRP Ledgerコミュニティに貢献するプロジェクトに開発者向けの助成金を提供します。
|
||||
"Past awardees include:": "過去の受賞者:"
|
||||
Visit XRPL Grants: XRPL Grantsを見る
|
||||
Software developers, teams, and start-ups building directly on the XRP Ledger: XRP Ledger上で直接開発を行うソフトウェア開発者やチーム、スタートアップ企業
|
||||
Coding experience: コーディング経験
|
||||
Github repository: Githubリポジトリ
|
||||
Project narrative/description: プロジェクトの説明
|
||||
At least one developer on the core team: 少なくとも1人のコアチーム開発者
|
||||
Budget and milestones: 予算とマイルストーン
|
||||
XRPL intermediate to advanced developers: XRPLの中級開発者から上級開発者
|
||||
$10,000 - $200,000: $10,000 ~ $200,000
|
||||
XRPL Accelerator: XRPLアクセラレータ
|
||||
Advance your project: プロジェクトの推進
|
||||
12-week program for entrepreneurs building on the XRP Ledger to scale their projects into thriving businesses.: XRP Ledgerをベースとする起業家向けの12週間のプログラムで、プロジェクトを繁栄するビジネスへとスケールアップさせることができます。
|
||||
Start-ups building scalable products on XRPL that can capture a large market opportunity: XRPL上でスケーラブルなプロダクトを構築し、大きな市場機会を獲得できるスタートアップ企業
|
||||
Strong founding team: 強力な創業チーム
|
||||
Bold, ambitious vision: 大胆で野心的なビジョン
|
||||
Ideally an MVP and monetization strategy: 理想的にはMVPと収益化戦略
|
||||
XRPL advanced developers: XRPLの上級開発者
|
||||
Business acumen: ビジネス知識
|
||||
View XRPL Accelerator: XRPLアクセラレータを見る
|
||||
$50,000 (grant) + pitch for venture funding: $50,000(助成金)＋ベンチャー資金へのピッチ
|
||||
|
||||
Open Source.: オープンソース
|
||||
Jump to top of page: ページの先頭へ
|
||||
Edit page: ページを編集
|
||||
Search: 検索
|
||||
Search site...: サイトを検索
|
||||
Search for articles, training, and code samples...: 記事、トレーニング、コードサンプルを検索...
|
||||
Start Building with Example Code: コードサンプルから開発を始める
|
||||
Code Samples: コードサンプル
|
||||
Browse sample code for building common use cases on the XRP Ledger: XRP Ledger上で一般的なユースケースを構築するためのコードサンプルを見ることができます
|
||||
Contribute Code Samples: コードサンプルへの貢献
|
||||
Help the XRPL community by submitting your<br> own code samples: コードサンプルを投稿して、XRPLコミュニティに貢献しましょう
|
||||
The XRPL Community: XRPL コミュニティ
|
||||
Find the community on the platforms below: 以下のプラットフォームでコミュニティにアクセスできます。
|
||||
Apply for funding to build your XRPL project: 将来のXRPLプロジェクトのための資金調達に応募する
|
||||
Awarded in a single grant: 1回のGrantでの助成金
|
||||
Distributed to grant recipients: 助成対象者への配布
|
||||
Open-source projects funded : オープンソースプロジェクトへの資金提供
|
||||
Learn More: もっと知る
|
||||
Showcase your XRPL project, application or product: XRPLプロジェクト、アプリケーション、製品の紹介
|
||||
Read the Blog: ブログを読む
|
||||
Check out global events across the XRPL community: XRPLコミュニティで開催されるグローバルなイベントをチェック
|
||||
XRPL Events: XRPLイベント
|
||||
Review guidelines for using XRPL design assets: XRPLのデザインアセットを使用するためのガイドラインを確認
|
||||
XRPL Assets: XRPLのアセット
|
||||
Download the PDF and Assets: PDFとアセットをダウンロード
|
||||
A community-driven resource for all things XRPL.org: XRPとXRP Ledgerのあらゆるものを提供する、コミュニティ主体のリソース
|
||||
Dev Tools: 開発者ツール
|
||||
Explorers: エクスプローラ
|
||||
API Access: APIアクセス
|
||||
Other: その他
|
||||
Have an Idea For a Tool?: ツールのアイデアをお持ちですか？
|
||||
Open a pull Request: プルリクエストを作成する
|
||||
Full documentation index: 全ドキュメントの目次
|
||||
See Everything: 全てを見る
|
||||
rippled API Reference: rippled APIリファレンス
|
||||
XRP Faucet: XRP Faucet
|
||||
Getting Started with Python: Pythonを使ってみよう
|
||||
Websocket API Tool: Websocket APIツール
|
||||
Trade on the decentralized exchange: 分散型取引所でトレード
|
||||
Make payments: 支払いを実行
|
||||
Use specialized payment types: 高度な支払い機能
|
||||
Non-fungible Tokens: 非代替性トークン
|
||||
Issue a stablecoin: ステーブルコインを発行
|
||||
Assign an authorized minter: 認可Minterの割り当て
|
||||
Peer to peer payments: 直接支払い
|
||||
Escrows: エスクロー
|
||||
Get Started: 始めましょう
|
||||
See full documentation index: 全ドキュメントの目次
|
||||
The XRPL Developer Summit: XRPL開発者サミット
|
||||
Save the Date: 日程を確認
|
||||
Upcoming Events: 今後のイベント情報
|
||||
Sorry, this page is not available in your language.: 申し訳ありませんが、このページはお使いの言語では提供されていません。
|
||||
References and APIs: リファレンスとAPI
|
||||
Everything You Need to Know: 全てはここに
|
||||
XRP Ledger address, transaction ID, or ledger index: XRP Ledgerアドレス、トランザクションID、またはレジャーインデックス
|
||||
@@ -278,29 +627,17 @@ Finish automatically: 自動的に終了
|
||||
Create Payment Channel: Payment Channelを作成
|
||||
Send Issued Currency: トークンを送信
|
||||
Trust for: トラストラインの設定
|
||||
Security: セキュリティ
|
||||
Release Notes: リリースノート
|
||||
Custody: カストディ
|
||||
Infrastructure: インフラストラクチャ
|
||||
Carbon Markets/Sustainability: 持続可能性
|
||||
Developer Tooling: 開発者ツール
|
||||
Gaming: ゲーム
|
||||
Wallet: ウォレット
|
||||
Ledger City is a crypto real estate game powered by the XRP Ledger.: Ledger Cityは、XRP Ledgerを利用した暗号不動産ゲームです。
|
||||
Interoperability: 相互運用性
|
||||
Ripple's CBDC Platform: Ripple社のCBDC Platform\
|
||||
Ripple's On-Demand Liquidity: Ripple社のOn-Demand Liquidity
|
||||
Exchanges: 取引所
|
||||
XRPL Rosetta explores fiat data on XRPL through visualization.: XRPL Rosettaは、XRPL上のフィアットデータを可視化することで素晴らしさを追求します。
|
||||
XRPL.org's Ledger Explorer is a block explorer of the XRP Ledger.: XRPL.orgのLedger Explorerは、XRP Ledgerのブロックエクスプローラーです。
|
||||
Xumm Wallet is a non custodial wallet with superpower for the XRP Ledger.: Xumm Walletは、XRP Ledgerのための最高能力を備えた非カストディアルウォレットです。
|
||||
Web Monetization: ウェブ収益化
|
||||
Sustainability: 持続可能性
|
||||
CBDCs: CBDC
|
||||
Cancel: キャンセル
|
||||
Featured Categories: 注目のカテゴリ
|
||||
Other Categories: 他のカテゴリ
|
||||
Proven Powerful for Innovation: イノベーションのための確かな実績
|
||||
XRPL Use Cases: XRPLのユースケース
|
||||
Building businesses and creating new value: ビジネスの構築と新たな価値の創造
|
||||
XRPL Ecosystem: XRPLエコシステム
|
||||
|
||||
97
@theme/components/LanguagePicker/LanguagePicker.tsx
Normal file
97
@theme/components/LanguagePicker/LanguagePicker.tsx
Normal file
@@ -0,0 +1,97 @@
|
||||
import React from 'react';
|
||||
import styled from 'styled-components';
|
||||
|
||||
import { DropdownMenu } from '@redocly/theme/components/Dropdown/DropdownMenu';
|
||||
import { breakpoints } from '@redocly/theme/core/utils';
|
||||
import { useLanguagePicker, useThemeHooks } from '@redocly/theme/core/hooks';
|
||||
import { GlobalOutlinedIcon } from '@redocly/theme/icons/GlobalOutlinedIcon/GlobalOutlinedIcon';
|
||||
import { Button } from '@redocly/theme/components/Button/Button';
|
||||
import { Dropdown } from '@redocly/theme/components/Dropdown/Dropdown';
|
||||
import { CheckmarkIcon } from '@redocly/theme/icons/CheckmarkIcon/CheckmarkIcon';
|
||||
|
||||
export type LanguagePickerProps = {
|
||||
onChangeLanguage: (newLang: string) => void;
|
||||
onlyIcon?: boolean;
|
||||
placement?: 'top' | 'bottom';
|
||||
alignment?: 'start' | 'end';
|
||||
};
|
||||
|
||||
export function LanguagePicker(props: LanguagePickerProps): JSX.Element | null {
|
||||
const { currentLocale, locales, setLocale } = useLanguagePicker();
|
||||
const { useTelemetry } = useThemeHooks();
|
||||
const telemetry = useTelemetry();
|
||||
|
||||
if (locales.length < 2 || !currentLocale) {
|
||||
return null;
|
||||
}
|
||||
|
||||
const languagePickerButton = (
|
||||
<Button
|
||||
icon={<GlobalOutlinedIcon color="--button-content-color" />}
|
||||
variant="text"
|
||||
size="medium"
|
||||
/>
|
||||
);
|
||||
|
||||
const languageItems = locales.map((locale) => ({
|
||||
content: locale.name || locale.code || '',
|
||||
onAction: () => {
|
||||
setLocale(locale.code);
|
||||
props.onChangeLanguage(locale.code);
|
||||
telemetry.send('language_picker_locale_changed', { locale: locale.code });
|
||||
},
|
||||
active: locale.code === currentLocale.code,
|
||||
suffix: locale.code === currentLocale.code && <CheckmarkIcon />,
|
||||
}));
|
||||
|
||||
return (
|
||||
<LanguageDropdown
|
||||
triggerEvent="click"
|
||||
placement={props.placement}
|
||||
alignment={props.alignment}
|
||||
trigger={languagePickerButton}
|
||||
>
|
||||
<DropdownMenu items={languageItems} />
|
||||
</LanguageDropdown>
|
||||
);
|
||||
}
|
||||
|
||||
const LanguageDropdown = styled(Dropdown).attrs(() => ({
|
||||
dataAttributes: {
|
||||
'data-component-name': 'LanguagePicker/LanguagePicker',
|
||||
},
|
||||
}))`
|
||||
--dropdown-menu-item-justify-content: space-between;
|
||||
--dropdown-menu-item-gap: var(--spacing-xxs);
|
||||
--dropdown-menu-font-size: var(--language-picker-dropdown-font-size);
|
||||
--dropdown-menu-font-weight: var(--language-picker-dropdown-font-weight);
|
||||
--dropdown-menu-line-height: var(--language-picker-dropdown-line-height);
|
||||
--dropdown-menu-text-color: var(--language-picker-dropdown-text-color);
|
||||
--dropdown-menu-min-width: var(--language-picker-dropdown-min-width);
|
||||
--dropdown-menu-max-width: var(--language-picker-dropdown-max-width);
|
||||
--dropdown-menu-max-height: var(--language-picker-dropdown-max-height);
|
||||
--dropdown-menu-padding: var(--language-picker-dropdown-padding);
|
||||
--dropdown-menu-border-radius: var(--language-picker-dropdown-border-radius);
|
||||
--dropdown-menu-box-shadow: var(--language-picker-dropdown-box-shadow);
|
||||
--dropdown-menu-border-color: var(--language-picker-dropdown-border-color);
|
||||
--dropdown-menu-bg-color: var(--language-picker-dropdown-bg-color);
|
||||
--dropdown-menu-item-padding-horizontal: var(--language-picker-dropdown-item-padding-horizontal);
|
||||
--dropdown-menu-item-padding-vertical: var(--language-picker-dropdown-item-padding-vertical);
|
||||
--dropdown-menu-item-separator-padding-top: var(
|
||||
--language-picker-dropdown-item-separator-padding-top
|
||||
);
|
||||
--dropdown-menu-item-separator-padding-bottom: var(
|
||||
--language-picker-dropdown-item-separator-padding-bottom
|
||||
);
|
||||
--dropdown-menu-item-border-radius: var(--language-picker-dropdown-item-border-radius);
|
||||
--dropdown-menu-item-bg-color-active: var(--language-picker-dropdown-item-bg-color-active);
|
||||
--dropdown-menu-item-bg-color-hover: var(--language-picker-dropdown-item-bg-color-hover);
|
||||
--dropdown-menu-item-bg-color-disabled: var(--language-picker-dropdown-item-bg-color-disabled);
|
||||
--dropdown-menu-item-separator-border-color: var(
|
||||
--language-picker-dropdown-item-separator-border-color
|
||||
);
|
||||
--dropdown-menu-item-color-dangerous: var(--language-picker-dropdown-item-color-dangerous);
|
||||
--dropdown-menu-item-color-disabled: var(--language-picker-dropdown-item-color-disabled);
|
||||
--dropdown-menu-item-color-active: var(--language-picker-dropdown-item-color-active);
|
||||
--dropdown-menu-item-color-hover: var(--language-picker-dropdown-item-color-hover);
|
||||
`;
|
||||
@@ -1,25 +1,25 @@
|
||||
import * as React from "react";
|
||||
import styled from "styled-components";
|
||||
import { useThemeConfig } from "@theme/hooks/useThemeConfig";
|
||||
import { LanguagePicker } from "@theme/i18n/LanguagePicker";
|
||||
import { useI18n, useTranslate } from "@portal/hooks";
|
||||
import { useThemeConfig, useThemeHooks } from "@redocly/theme/core/hooks";
|
||||
import { LanguagePicker } from "@redocly/theme/components/LanguagePicker/LanguagePicker";
|
||||
import { slugify } from "../../helpers";
|
||||
import { Link } from "@portal/Link";
|
||||
import { ColorModeSwitcher } from "@theme/components/ColorModeSwitcher/ColorModeSwitcher";
|
||||
import { Search } from "@theme/components/Search/Search";
|
||||
import { Link } from "@redocly/theme/components/Link/Link";
|
||||
import { ColorModeSwitcher } from "@redocly/theme/components/ColorModeSwitcher/ColorModeSwitcher";
|
||||
import { Search } from "@redocly/theme/components/Search/Search";
|
||||
|
||||
// @ts-ignore
|
||||
|
||||
const alertBanner = {
|
||||
show: true,
|
||||
show: false,
|
||||
message: "XRP Ledger Apex is back in Amsterdam",
|
||||
button: "Register Now",
|
||||
link: "https://www.xrpledgerapex.com/?utm_source=xrplorg&utm_medium=web&utm_campaign=banner",
|
||||
link: "https://www.xrpledgerapex.com/?utm_source=email&utm_medium=email_marketing&utm_campaign=EVENTS_XRPL_Apex_2024_Q2&utm_term=events_page_cta_button",
|
||||
};
|
||||
|
||||
export function Navbar(props) {
|
||||
// const [isOpen, setIsOpen] = useMobileMenu(false);
|
||||
const themeConfig = useThemeConfig();
|
||||
const { useI18n } = useThemeHooks();
|
||||
const { changeLanguage } = useI18n();
|
||||
const menu = themeConfig.navbar?.items;
|
||||
const logo = themeConfig.logo;
|
||||
@@ -92,7 +92,7 @@ export function Navbar(props) {
|
||||
button={alertBanner.button}
|
||||
link={alertBanner.link}
|
||||
/>
|
||||
<NavWrapper belowAlertBanner={true}>
|
||||
<NavWrapper belowAlertBanner={alertBanner.show}>
|
||||
<LogoBlock to={href} img={logo} alt={altText} />
|
||||
<NavControls>
|
||||
<MobileMenuIcon />
|
||||
@@ -104,10 +104,10 @@ export function Navbar(props) {
|
||||
<Search className="topnav-search" />
|
||||
</div>
|
||||
<div id="topnav-language" className="nav-item">
|
||||
<LanguagePicker onChangeLanguage={changeLanguage} onlyIcon />
|
||||
<LanguagePicker onChangeLanguage={changeLanguage} onlyIcon alignment="end" />
|
||||
</div>
|
||||
<div id="topnav-theme" className="nav-item">
|
||||
<StyledColorModeSwitcher />
|
||||
<ColorModeSwitcher />
|
||||
</div>
|
||||
</NavItems>
|
||||
</TopNavCollapsible>
|
||||
@@ -120,37 +120,40 @@ const StyledColorModeSwitcher = styled(ColorModeSwitcher)`
|
||||
padding: 10px;
|
||||
`;
|
||||
|
||||
export function AlertBanner(props) {
|
||||
const { message, button, link } = props;
|
||||
return (
|
||||
<div className="top-banner fixed-top">
|
||||
<div className="inner-apex">
|
||||
<span>
|
||||
<p className="mb-0 apex-banner-text">{message}</p>
|
||||
</span>
|
||||
<span>
|
||||
<a href={link} target="_blank" className="apex-btn">
|
||||
{button}
|
||||
</a>
|
||||
</span>
|
||||
export function AlertBanner({ message, button, link, show }) {
|
||||
if (show) {
|
||||
return (
|
||||
<div className="top-banner fixed-top">
|
||||
<div className="inner-apex">
|
||||
<span>
|
||||
<p className="mb-0 apex-banner-text">{message}</p>
|
||||
</span>
|
||||
<span>
|
||||
<Link to={link} target="_blank" className="apex-btn">
|
||||
{button}
|
||||
</Link>
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
);
|
||||
);
|
||||
}
|
||||
return null;
|
||||
}
|
||||
|
||||
export function TopNavCollapsible(props) {
|
||||
export function TopNavCollapsible({children}) {
|
||||
return (
|
||||
<div
|
||||
className="collapse navbar-collapse justify-content-between"
|
||||
id="top-main-nav"
|
||||
>
|
||||
{props.children}
|
||||
{children}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
export function NavDropdown(props) {
|
||||
const { label, items, pathPrefix, labelTranslationKey } = props;
|
||||
const { useTranslate } = useThemeHooks();
|
||||
const { translate } = useTranslate();
|
||||
|
||||
const dropdownGroups = items.map((item, index) => {
|
||||
@@ -164,9 +167,9 @@ export function NavDropdown(props) {
|
||||
item2_href = pathPrefix + item2_href;
|
||||
}
|
||||
return (
|
||||
<a key={index2} className={cls2} href={item2_href}>
|
||||
<Link key={index2} className={cls2} to={item2_href}>
|
||||
{translate(item2.labelTranslationKey, item2.label)}
|
||||
</a>
|
||||
</Link>
|
||||
);
|
||||
});
|
||||
|
||||
@@ -174,7 +177,9 @@ export function NavDropdown(props) {
|
||||
|
||||
return (
|
||||
<div key={index} className={clnm}>
|
||||
<h5 className="dropdown-item">{translate(item.labelTranslationKey, item.label)}</h5>
|
||||
<h5 className="dropdown-item">
|
||||
{translate(item.labelTranslationKey, item.label)}
|
||||
</h5>
|
||||
{groupLinks}
|
||||
</div>
|
||||
);
|
||||
@@ -187,7 +192,7 @@ export function NavDropdown(props) {
|
||||
hero_href = pathPrefix + hero_href;
|
||||
}
|
||||
const splitlabel = item.label.split(" || ");
|
||||
let splittranslationkey = ["",""]
|
||||
let splittranslationkey = ["", ""];
|
||||
if (item.labelTranslationKey) {
|
||||
splittranslationkey = item.labelTranslationKey.split(" || ");
|
||||
}
|
||||
@@ -195,18 +200,18 @@ export function NavDropdown(props) {
|
||||
const description = translate(splittranslationkey[1], splitlabel[1]); // splitlabel[1] might be undefined, that's ok
|
||||
|
||||
return (
|
||||
<a
|
||||
<Link
|
||||
key={index}
|
||||
className="dropdown-item dropdown-hero"
|
||||
id={hero_id}
|
||||
href={hero_href}
|
||||
to={hero_href}
|
||||
>
|
||||
<img id={item.hero} alt={img_alt} src={item.icon} />
|
||||
<div className="dropdown-hero-text">
|
||||
<h4>{newlabel}</h4>
|
||||
<p>{description}</p>
|
||||
</div>
|
||||
</a>
|
||||
</Link>
|
||||
);
|
||||
} else {
|
||||
const cls = item.external
|
||||
@@ -217,9 +222,9 @@ export function NavDropdown(props) {
|
||||
item_href = pathPrefix + item_href;
|
||||
}
|
||||
return (
|
||||
<a key={index} className={cls} href={item_href}>
|
||||
<Link key={index} className={cls} to={item_href}>
|
||||
{translate(item.labelTranslationKey, item.label)}
|
||||
</a>
|
||||
</Link>
|
||||
);
|
||||
}
|
||||
});
|
||||
@@ -283,16 +288,17 @@ export function MobileMenuIcon() {
|
||||
}
|
||||
|
||||
export function GetStartedButton() {
|
||||
const { useTranslate } = useThemeHooks();
|
||||
const { translate } = useTranslate();
|
||||
|
||||
return (
|
||||
<a
|
||||
<Link
|
||||
className="btn btn-primary"
|
||||
href={"/docs/tutorials"}
|
||||
to={"/docs/tutorials"}
|
||||
style={{ height: "38px", paddingTop: "11px" }}
|
||||
>
|
||||
{translate("Get Started")}
|
||||
</a>
|
||||
</Link>
|
||||
);
|
||||
}
|
||||
|
||||
@@ -311,9 +317,9 @@ export function NavItem(props) {
|
||||
export function LogoBlock(props) {
|
||||
const { to, img, altText } = props;
|
||||
return (
|
||||
<a className="navbar-brand" href="/">
|
||||
<Link className="navbar-brand" to="/">
|
||||
<img className="logo" alt={"XRP LEDGER"} height="40" src="data:," />
|
||||
</a>
|
||||
</Link>
|
||||
);
|
||||
}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
import * as React from 'react';
|
||||
import dynamicReact from '@markdoc/markdoc/dist/react';
|
||||
import { Link } from '@portal/Link';
|
||||
import { Link } from '@redocly/theme/components/Link/Link';
|
||||
|
||||
export interface XRPLCardProps {
|
||||
title: string,
|
||||
|
||||
@@ -2,8 +2,8 @@ import * as React from 'react';
|
||||
import { useLocation } from 'react-router-dom';
|
||||
// @ts-ignore
|
||||
import dynamicReact from '@markdoc/markdoc/dist/react';
|
||||
import { usePageSharedData, useTranslate } from '@portal/hooks';
|
||||
import { Link } from '@portal/Link';
|
||||
import { Link } from '@redocly/theme/components/Link/Link';
|
||||
import { useThemeHooks } from '@redocly/theme/core/hooks'
|
||||
import { idify } from '../helpers';
|
||||
|
||||
export {default as XRPLoader} from '../components/XRPLoader';
|
||||
@@ -11,6 +11,7 @@ export { XRPLCard, CardGrid } from '../components/XRPLCard';
|
||||
|
||||
|
||||
export function IndexPageItems() {
|
||||
const { usePageSharedData } = useThemeHooks();
|
||||
const data = usePageSharedData('index-page-items') as any[];
|
||||
return (
|
||||
<div className="children-display">
|
||||
@@ -148,6 +149,7 @@ function shieldsIoEscape(s: string) {
|
||||
}
|
||||
|
||||
export function NotEnabled() {
|
||||
const { useTranslate } = useThemeHooks();
|
||||
const { translate } = useTranslate();
|
||||
return (
|
||||
<span className="status not_enabled" title={translate("This feature is not currently enabled on the production XRP Ledger.")}><i className="fa fa-flask"></i></span>
|
||||
|
||||
@@ -122,6 +122,10 @@ export const badge: Schema & { tagName: string } = {
|
||||
href: {
|
||||
type: 'String',
|
||||
required: false
|
||||
},
|
||||
date: { // Not displayed, but useful for knowing how old an 'updated' badge is
|
||||
type: 'String',
|
||||
required: false
|
||||
}
|
||||
},
|
||||
render: 'Badge'
|
||||
|
||||
@@ -43,6 +43,7 @@ export function codeSamples() {
|
||||
|
||||
actions.createSharedData('code-samples', { codeSamples: sortedSamples, langs: Array.from(allLands) });
|
||||
actions.addRouteSharedData('/resources/code-samples/', 'code-samples', 'code-samples');
|
||||
actions.addRouteSharedData('/ja/resources/code-samples/', 'code-samples', 'code-samples');
|
||||
} catch (e) {
|
||||
console.log(e);
|
||||
}
|
||||
|
||||
@@ -163,29 +163,26 @@ ul.nav.navbar-nav {
|
||||
--color-primary-text: #161087;
|
||||
--color-primary-text-active: #0d086e;*/
|
||||
|
||||
--link-text-color: #fff;
|
||||
--link-color-primary: #fff;
|
||||
--link-decoration: underline;
|
||||
--link-font-weight: var(--font-weight-regular);
|
||||
|
||||
--link-hover-text-color: #9a52ff;
|
||||
--link-hover-decoration: underline;
|
||||
--link-color-primary-hover: #9a52ff;
|
||||
--link-decoration-hover: underline;
|
||||
|
||||
--link-active-decoration: underline;
|
||||
--link-active-text-color: var(--color-blue-7);
|
||||
|
||||
--link-visited-text-color: #fff;
|
||||
--link-color-visited: #fff;
|
||||
--link-visited-decoration: underline;
|
||||
|
||||
--bg-base: var(--color-gray-10);
|
||||
--bg-raised: var(--color-gray-8);
|
||||
--background-color: var(--bg-base);
|
||||
--bg-color: var(--color-gray-10);
|
||||
--bg-color-raised: var(--color-gray-8);
|
||||
--background-color: var(--bg-color);
|
||||
|
||||
--font-family-base: 'Work Sans', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
|
||||
--heading-font-family: var(--font-family-base);
|
||||
|
||||
--inline-code-font-family: "Space Mono", monospace;
|
||||
--inline-code-text-color: #5beb9d; /* $green-400 */
|
||||
--inline-code-background-color: #0a2e1b; /* $green-1000 */
|
||||
--inline-code-bg-color: #0a2e1b; /* $green-1000 */
|
||||
--inline-code-border-radius: 0;
|
||||
|
||||
--heading-anchor-color: #9a52ff;
|
||||
@@ -194,68 +191,98 @@ ul.nav.navbar-nav {
|
||||
--h3-font-size: 2.125rem;
|
||||
--h3-font-weight: 600;
|
||||
--h4-font-size: 1.75rem;
|
||||
--h4-line-height: 2rem;
|
||||
--h5-font-size: 1.25rem;
|
||||
--h5-line-height: 1.5rem;
|
||||
|
||||
--sidebar-border-color: transparent;
|
||||
--sidebar-background-color: transparent;
|
||||
|
||||
--search-item-active-text-color: #E8E9E7;
|
||||
--sidebar-bg-color: transparent;
|
||||
--sidebar-margin-horizontal: 32px;
|
||||
|
||||
--border-radius-md: 4px;
|
||||
|
||||
--code-block-background-color: #232325;
|
||||
--code-block-controls-background-color: #232325;
|
||||
--code-block-bg-color: #232325;
|
||||
--code-block-controls-bg-color: #232325;
|
||||
--code-block-controls-border: none;
|
||||
--code-block-border-color: #232325;
|
||||
--code-block-padding: 0 2rem 1.5rem 2rem;
|
||||
--code-block-border-radius: 4px;
|
||||
|
||||
--breadcrumbs-margin-bottom: 0.5rem;
|
||||
--breadcrumbs-text-color: var(--color-gray-4);
|
||||
--breadcrumbs-gap: 0 8px;
|
||||
--breadcrumbs-font-size: 0.833em;
|
||||
|
||||
--language-picker-min-height: 38px;
|
||||
|
||||
--footer-background-color: transparent;
|
||||
--footer-dividing-border-color: transparent;
|
||||
--footer-bg-color: transparent;
|
||||
--footer-column-divider-color: transparent;
|
||||
--footer-border-color: transparent;
|
||||
--footer-title-font-weight: 600;
|
||||
--footer-title-font-size: 1rem;
|
||||
--footer-title-text-color: #A2A2A4;
|
||||
|
||||
--sidebar-margin-horizontal: 32px;
|
||||
--sidebar-item-padding-horizontal: 0;
|
||||
--menu-item-padding-horizontal: 0px;
|
||||
|
||||
--md-list-left-padding: 40px;
|
||||
--md-table-header-bg-color: #32343E;
|
||||
--md-table-border-color: #32343E;
|
||||
}
|
||||
|
||||
:root.light {
|
||||
--link-hover-text-color: #4A00B2;
|
||||
--link-visited-text-color: #000;
|
||||
--text-secondary: #000;
|
||||
--code-block-background-color: #E0E0E1;
|
||||
--code-block-controls-background-color: #E0E0E1;
|
||||
--link-color-primary-hover: #4A00B2;
|
||||
--link-color-visited: #000;
|
||||
--text-color-secondary: #000;
|
||||
--code-block-bg-color: #E0E0E1;
|
||||
--code-block-controls-bg-color: #E0E0E1;
|
||||
--code-block-controls-border: none;
|
||||
--code-block-border-color: #E0E0E1;
|
||||
--md-tabs-active-tab-background-color: #C1C1C2;
|
||||
--md-tabs-active-tab-bg-color: #C1C1C2;
|
||||
|
||||
--code-block-tokens-function-color: #B23C00;
|
||||
--code-block-tokens-operator-color: #000;
|
||||
--code-block-tokens-comment-color: #343437;
|
||||
--code-block-tokens-string-color: #145C35;
|
||||
--inline-code-background-color: #E0E0E1;
|
||||
--inline-code-bg-color: #E0E0E1;
|
||||
|
||||
--search-trigger-bg-color: #E0E0E1;
|
||||
--search-trigger-color: #838386;
|
||||
|
||||
--search-trigger-background-color: #E0E0E1;
|
||||
--search-trigger-text-color: #838386;
|
||||
--language-picker-border-color: #C1C1C2;
|
||||
--language-picker-background-color: #E0E0E1;
|
||||
--select-list-background-color: #E0E0E1;
|
||||
--select-list-bg-color: #E0E0E1;
|
||||
|
||||
--footer-title-text-color: #000;
|
||||
--bg-base: var(--color-gray-1);
|
||||
--bg-raised: var(--color-gray-2);
|
||||
--button-background-color: var(--color-gray-2);
|
||||
--bg-color: var(--color-gray-1);
|
||||
--bg-color-raised: var(--color-gray-2);
|
||||
--button-content-color-link: #000;
|
||||
|
||||
--md-table-header-bg-color: var(--color-gray-2);
|
||||
--md-table-border-color: var(--color-gray-2);
|
||||
}
|
||||
|
||||
:root.dark {
|
||||
--link-color-primary: #fff;
|
||||
--link-color-visited: #fff;
|
||||
--link-color-primary-hover: #9a52ff;
|
||||
}
|
||||
|
||||
:root .form-control-plaintext {
|
||||
color: var(--text-color);
|
||||
}
|
||||
|
||||
[data-component-name="Search/SearchTrigger"] > div {
|
||||
justify-content: start;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
[data-component-name="Markdown/Markdown"] {
|
||||
--md-table-font-size: 14px;
|
||||
}
|
||||
|
||||
@media screen and (min-width: 990px) {
|
||||
[data-component-name="LanguagePicker/LanguagePicker"] {
|
||||
display: block;
|
||||
}
|
||||
[data-component-name="Search/SearchTrigger"] > button {
|
||||
display: none;
|
||||
}
|
||||
[data-component-name="Search/SearchTrigger"] > div {
|
||||
display: inline-flex;
|
||||
}
|
||||
}
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user