- Introduced the FeatureTwoColumn pattern for showcasing features in a two-column layout, supporting multiple color themes and responsive design.
- Implemented button behavior based on the number of links, with configurations for 1 to 5 links.
- Added `forceColor` prop to Button component to maintain button color across light and dark themes, particularly useful for colored backgrounds.
- Updated styles and documentation for both the FeatureTwoColumn pattern and Button component to reflect new features and usage guidelines.
- Added keyboard navigation support to NavItems, allowing users to close submenus with the Escape key and toggle with Enter/Space.
- Implemented onClose callback in Submenu components to facilitate submenu closure.
- Updated Navbar to handle submenu closing for keyboard navigation.
- Adjusted styles for better layout and responsiveness in submenus.
- Updated Button component styles to use responsive typography mixins for better adaptability across devices.
- Removed redundant media queries and adjusted font sizes and line heights for both button types.
- Ensured margin resets to maintain consistent spacing in various contexts.
- Enhanced CSS for improved readability and maintainability.
- Adjusted column spans in CardImage showcase to support a 4-column layout on larger screens.
- Updated TileLogo showcase to reflect changes in aspect ratios and responsive behavior, ensuring proper display across different screen sizes.
- Enhanced SCSS styles for both components to maintain consistency in appearance and functionality in light and dark themes.
- Refined documentation to clarify usage and responsive design principles for both CardImage and TileLogo components.
- Changed tablet aspect ratio from 2:1 to 16:9 for better compatibility with an 8-column grid.
- Adjusted title alignment in the title-only layout from center to top for improved visual hierarchy.
- Updated .bds-submenu__section to use justify-content: space-between for better distribution of space between header and items.
- Removed gap property and set margin-top to 0 for .bds-submenu__tier2 to enhance visual alignment in Use Cases section.
- Introduced LanguageDropdown for improved language selection in Navbar and MobileMenu.
- Updated LanguagePill to display the current language dynamically and manage dropdown state.
- Enhanced styles for language-related components to support open/close states and transitions.
- Added mobile-specific dropdown positioning and styles for better user experience.
- Introduced a new SCSS mixin for theme mode that applies styles based on light or dark themes, with validation for mode parameters.
- Updated CardIcon styles to maintain background color on focus for both light and green themes, enhancing accessibility and user experience.
- Removed unnecessary import from SmallTilesSection styles to streamline the codebase.
- Update "Send a Time-Held Escrow" to "Send a Timed Escrow" with new
code samples in JS and Python.
- Update "Send a Conditionally-Held Escrow" to "Send a Conditional
Escrow" with new code samples in JS and Python.
- Update "Cancel an Expired Escrow" and "Look Up Escrows" with new code
samples.
- Remove translations of the old tutorials, which are substantially
different from the new tutorials.
- Remove websocket API examples that were used in the old tutorials.
- Remove the "Use Escrow as a Smart Contract" article, which was an
awkward mix between a use case and a tutorial.
- Update sidebars and redirects for the removed and renamed tutorials.
- Introduced the SmallTilesSection component for displaying multiple CardIcon components in a responsive grid layout.
- Implemented SCSS styles for the SmallTilesSection, including responsive grid behavior and spacing adjustments.
- Added documentation for the SmallTilesSection component, detailing usage, props, and examples.
- Updated main stylesheet to include SmallTilesSection styles.
- Updated spacing variables for tablet view to enhance layout consistency.
- Introduced accent-specific spacing for title and description groups on tablet and desktop.
- Adjusted margin and gap values for improved responsiveness and visual hierarchy.
- Refactored color variables to use design tokens for better maintainability.
- Ensured consistent text colors for titles and descriptions in both light and dark modes.
- Adjusted color values for better contrast and readability across themes.
- Introduced new styles for the HeaderHeroSplitMedia component, including layout, typography, and responsive design adjustments.
- Updated margin-bottom for paragraph and label-r elements to enhance spacing consistency.
- Updated Button component styles to use responsive typography mixins for better adaptability across devices.
- Removed redundant media queries and adjusted font sizes and line heights for both button types.
- Ensured margin resets to maintain consistent spacing in various contexts.
- Enhanced CSS for improved readability and maintainability.
- Adjusted column spans in CardImage showcase to support a 4-column layout on larger screens.
- Updated TileLogo showcase to reflect changes in aspect ratios and responsive behavior, ensuring proper display across different screen sizes.
- Enhanced SCSS styles for both components to maintain consistency in appearance and functionality in light and dark themes.
- Refined documentation to clarify usage and responsive design principles for both CardImage and TileLogo components.
- Introduced link button support in the Button component, allowing buttons to render as anchor elements when an `href` prop is provided.
- Updated Button showcase to demonstrate link buttons for internal and external navigation.
- Enhanced Button SCSS styles to ensure proper appearance and behavior for link buttons in both light and dark themes.
- Added documentation for link button usage in the Button showcase.
- Added a new image scaling demonstration to the CardImage showcase, illustrating a zoom effect on hover.
- Updated layout of CardImage components to improve responsiveness, adjusting column spans for various screen sizes.
- Introduced a new image from Figma for the scaling demo and included detailed descriptions of the scaling behavior.
- Refined SCSS styles to support the new layout and ensure consistent spacing across different screen sizes.
- Introduced the CardImage component, a responsive card designed to display an image, title, subtitle, and call-to-action button.
- Implemented three responsive size variants (LG, MD, SM) that adapt to viewport width.
- Added interactive states including default, hover, focus, pressed, and disabled.
- Created a comprehensive showcase page demonstrating all variants and states of the CardImage component.
- Included detailed documentation covering usage examples, props API, design tokens, and accessibility features.
- Added SCSS styles for the CardImage component, ensuring compatibility with both light and dark themes.
- Introduced the CardIcon component, a clickable card featuring an icon and label text, supporting two color variants (Neutral and Green) and five interaction states (Default, Hover, Focused, Pressed, Disabled).
- Implemented responsive sizing that adapts at breakpoints (SM, MD, LG).
- Created a comprehensive showcase page demonstrating all variants, states, and usage examples.
- Added detailed documentation covering usage guidelines, best practices, and API reference.
- Included SCSS styles for the CardIcon component, ensuring compatibility with both light and dark themes.
- Updated CardOffgrid component to use .subhead-lg-l and .body-l classes for title and description typography, respectively.
- Removed custom font size and line height definitions from SCSS and CSS files for improved consistency and maintainability.
- Adjusted related styles to ensure compatibility with the new typography approach.
- Replaced div-based layout with PageGridRow and PageGridCol components for better responsiveness and alignment.
- Updated all instances of logo displays within the TileLogo showcase to utilize the new grid structure.
- Ensured consistent spacing and alignment across different logo variants and states.
- Updated SCSS styles to replace 'tile-logo' namespace with 'bds-tile-logo' for consistency with the Brand Design System.
- Adjusted class names in the TileLogo component to reflect the new naming convention.
- Ensured all styles and variants (square, rectangle, neutral, green) are updated accordingly for both light and dark themes.
- Introduced the TileLogo component, designed for displaying brand logos with interactive states.
- Implemented two shape variants (Square and Rectangle) and two color variants (Neutral and Green), with responsive sizing.
- Created a comprehensive showcase page demonstrating all variants, states, and usage examples.
- Added detailed documentation covering usage guidelines, best practices, and API reference.
- Included SCSS styles for the TileLogo component, ensuring compatibility with both light and dark themes.
- Introduced the CardOffgrid component, designed for displaying feature highlights with customizable icons, titles, and descriptions.
- Implemented two color variants: neutral and green, with interactive states and a unique hover animation.
- Created a comprehensive showcase page demonstrating all variants and states of the CardOffgrid component.
- Added detailed documentation covering usage guidelines, best practices, and API reference.
- Included SCSS styles for the CardOffgrid component, ensuring compatibility with both light and dark themes.
- Changed all instances of 'black' to 'base' in the Divider component and its documentation to reflect the new high-contrast color that adapts to light and dark themes.
- Updated showcase page and styles to ensure consistency with the new color naming convention.
- Introduced the Divider component following the XRPL Brand Design System, supporting horizontal and vertical orientations, three stroke weights (thin, regular, strong), and three color variants (gray, black, green).
- Created a comprehensive showcase page for the Divider component, demonstrating its usage and variations.
- Added detailed documentation for the Divider component, including props API, usage examples, and best practices.
- Included styles for the Divider component in SCSS format, ensuring compatibility with light and dark themes.
Updated button styles to enhance responsiveness across devices by replacing fixed breakpoints with a mixin for the xl breakpoint. Adjusted typography and padding for smaller screens to ensure consistent appearance and usability. Improved comments for clarity on the import order and design tokens.
- Introduced new styles for BDS link icons, including hover and focus states.
- Updated existing link styles to exclude BDS links from certain color and hover effects.
- Ensured consistent styling across light and dark themes for BDS links.
- Refactored landing page link styles to accommodate new BDS link classes.
Updated the styles for the tertiary button in dark mode, including hover, focus, active, and disabled states. Adjusted padding and added text decoration for better visual feedback. Enhanced responsiveness for smaller screens to ensure consistent behavior across devices.
Introduced a new ButtonShowcaseTertiary component to demonstrate the BDS Tertiary Button, including its various states and usage examples. Removed the previous ButtonShowcase component to streamline the showcase and focus on the Tertiary variant. Updated Button component to support the new variant and adjusted related styles in the CSS for both green and black themes.
- Introduced new events: XRPL Town Hall Meeting #5 and XRPL Aquarium Residency Demo Day #7 with relevant details.
- Updated the date format for the existing hackathon event.
- Replaced images for the hackathon event with the new Italy Hackathon image.
- Added new images for the Town Hall Meeting and Aquarium Residency events.
- Replace the old link with a link to the updated source version
- Add the missing "Source" title attribute so the source link will float right as intended
- Remove deprecated frontmatter
- Replace the old link with a link to the updated source version
- Add the missing "Source" title attribute so the source link will float right as intended
- Remove deprecated frontmatter
- Updated the structure of the tokenization page to improve readability and organization.
- Introduced new sections for video content and benefits, enhancing user engagement.
- Adjusted CSS styles for better responsiveness and alignment with design standards.
- Added a new margin utility class in _helpers.scss for consistent spacing.
- Improved the developer resources section to handle single card layouts more effectively.
- Added padding to the developer tools section within the tokenization page for improved layout.
- Updated CSS variables in devportal2024-v1.css for consistency and future styling adjustments.
- Corrected the class name from `.fiipay` to `.friipay` in the _use-cases.scss file to ensure proper image rendering.
- No changes made to the devportal2024-v1.css file, but it remains updated for future styling adjustments.
- Added max-width and margin adjustments to the payments integration section for better alignment on larger screens.
- Implemented responsive breakpoints for the payments integration section to ensure optimal display on medium and large devices.
- Introduced new styles for light mode payment logos and embedded payments icons, enhancing visual consistency across the payments page.
- Simplified the hero section by removing unnecessary container classes.
- Adjusted padding and margins in the payments styles to enhance layout consistency across various screen sizes.
- Updated media queries to ensure better responsiveness for video content and typography on smaller devices.
- Integrated DeveloperResourcesSection into both payments and tokenization pages to provide developers with essential resources and community links.
- Updated payment URLs for various stablecoins to direct users to relevant external resources.
- Improved layout and styling for the payments integration section, ensuring better responsiveness and user experience.
- Refactored CSS for shared developer tools styles between payments and tokenization pages, enhancing visual consistency.
- Replaced the manual benefits list in the index page with the BenefitsSection component for improved maintainability.
- Added BenefitsSection to the payments page, showcasing embedded payment use cases with new card data.
- Updated ProjectCards component to support optional button text for enhanced project presentation.
- Introduced new CSS styles for embedded payments icons and battle-tested project cards for better visual consistency.
- Changed the payments page to use `index.page.tsx` instead of `index.md` for better component integration.
- Added `AdvantagesSection` and `ProjectCards` components to both payments and tokenization pages to enhance content presentation.
- Adjusted CSS styles for improved responsiveness and layout consistency across different screen sizes.
- Removed outdated security card implementation in tokenization page and replaced it with a more streamlined advantages section.
Fix#3043.
The order of same-cost transactions in the queue was updated in [rippled 1.8.2](https://github.com/XRPLF/rippled/releases/tag/1.8.2), released in 2021, to address issues with high fees and full transaction queues on the network at the time.
- Add Currency, Issue, Number, and additional UInt fields.
- Harmonize type names with updated names from the code
(for example, Hash128→UInt128)
- Update Python sample code for binary serialization.
- TODO: Add test cases and confirm implementation of new types
- TODO: Update JavaScript sample code.
In certain cases, future `tec` codes may have other side effects on the ledger. For example, `tecWASM_REJECTED` is expected to be able to modify the value of the (new) "Data" field in the Escrow ledger entry.
2025-04-11 16:29:44 -07:00
1270 changed files with 99146 additions and 21584 deletions
@@ -41,7 +41,7 @@ Si un actor malicioso descubre la clave secreta de la dirección emisora de una
### 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.
Una institución financiera puede emitir más de un token en el XRP Ledger desde una única dirección de emisión. Sin embargo, hay algunas configuraciones que se aplican por igual a todos los tokens (fungibles) emitidos desde una dirección, incluido el porcentaje de [comisiones de transferencia](../tokens/fungible-tokens/transfer-fees.md) y el estado [congelación global](../tokens/fungible-tokens/freezes.md). Si la intitución financiera quiere la flexibilidad de manejar las configuraciones de distinta manera para cada token, la institución debe tener múltiples direcciones emisoras.
@@ -110,7 +110,7 @@ Puedes utilizar el [método deposit_authorized][] para ver si una cuenta esta au
- 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.
- [Pagos parciales](../payment-types/partial-payments.md) provee una forma para que cuentas puedan devolver pagos no deseados restando los [costes de transferencia](../tokens/fungible-tokens/transfer-fees.md) y los ratios de exchanges de la cantidad enviada en lugar de sumarlos a la cantidad enviada.
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
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.
seo:
description: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
@@ -74,7 +74,7 @@ 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).
**Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/index.md).
2. Si la UNL negativa no está llena, cada servidor propone añadir **hasta 1** validador a la UNL negativa entre sus validadores confiables con una fiabilidad inferior al 50%.
3. Si la UNL negativa no está vacía, cada servidor propone eliminar **hasta 1** validador de la UNL negativa. Un servidor puede proponer eliminar un validador de la UNL negativa por dos motivos:
@@ -82,7 +82,7 @@ En cada flag ledger, se aplican todos los siguientes cambios:
- 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.
Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/index.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.
Los cambios programados y efectivos de la UNL negativa se rastrean en el [objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md) en los datos de estado del ledger.
@@ -58,14 +58,6 @@ Los proveedores de servidores Full History se reservan el derecho de bloquear ac
Para instrucciones de cómo configurar un servidor full history, consultar [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
## 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
@@ -76,7 +68,6 @@ Para más información, ver [Configurar History Sharding](../../infrastructure/c
@@ -17,8 +17,6 @@ Para ayudar a miembros de la comunidad del XRP Ledger a interactuar con la tecno
| 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.
@@ -14,7 +14,6 @@ El software del servidor `rippled` puede ejecutarse en varios modos dependiendo
- [**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.)
@@ -67,18 +66,6 @@ Puedes habilitar de forma segura la validación en un servidor que también se u
Para más información sobre como ejecutar un validador, ver [Ejecutar `rippled` como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).
## Modo 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:
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.
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/fungible-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`.
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.
En esta fórmula, "costes" o fees se refiere a [costes de transferencia](../tokens/fungible-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.
| `--nodetoshard` | 完全に起動する前に、すべての完全な[履歴シャード](configuration/data-retention/history-sharding.md)をレジャーストアーからシャードストアーにコピーしてください（シャードストアーに設定されている最大ディスク容量まで）。CPUとI/Oを大量に使用します。注意: このコマンドは、データを（移動するのではなく）コピーするため、シャードストアーとレジャーストアーの両方にデータを保存するのに十分なディスク容量が必要です。 <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
