- 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.
- The code samples page was glitching out because it wasn't in a
language subfolder. Moved to a js/ folder to fix this.
- Updated pages that linked to the old location.
- The UI as linked directly in the _code-samples folder was displaying
as expected but the JS wasn't loading correctly on the page, so none
of the buttons worked. For now, I changed the Broker an NFT Sale
page to link the ZIP instead.
- 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.
The "MPT Payments" section of this page is one of the first search results for MPTs. This seems like a place where it's useful to link back to the concept article for MPTs.
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.
Adds a code sample and a code walkthrough explaining how to build a
service that issues Credentials (XLS-70) on the XRP Ledger.
Credential issuer: Clarify/revise documents field
Issue credentials code sample: fix bugs
Apply suggestions from @oeggert review
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
Credential Issuer: more edits for clarity
- Update modal content styling for better responsiveness
- Adjust logo sizing and positioning in use case modals
- Prevent horizontal scrolling and improve container layout
- Fine-tune spacing and alignment of modal elements
- The description gets deleted if it matches the title exactly (due to
how our plugin finds the text of the README). Changed a couple
instances to not match exactly so this doesn't happen.
- Changed the top level of the Code Sampels layout to be a <main>
element, which allows some styles to apply correctly and also helps
the search crawler find the contents of the page.
Apply suggestions from @tequdev review
Co-authored-by: tequ <git@tequ.dev>
Add credential transactions and amendment to common links
Add not-enabled warnings on Credentials docs.
- Introduced multiple new events including:
- XRPL Meetup in London on January 30, 2025
- XRPL Community Magazine #4 Launch Executive Breakfast in Paris on February 5, 2025
- Building on the XRP Ledger training in Paris from January 27-28, 2025
- Added corresponding images for the new events.
- Removed unused import of React in events.page.tsx.
Per a comment from a Ripple employee, he wasn't able to figure out where the trust line information was stored. RippleState linked to the Trust Line topic, but not vice-versa.
Per Redocly, we can't call useThemeHooks for translation in the TOML
validator dependencies the way they're used right now. Since I'm unclear
on how to refactor it to work with useThemeHooks right now, I'm removing
the calls to useTranslate so that the tool will at least work in
English.
Updated description for `LastUpdateTime` field as per the (PR comments)[https://github.com/XRPLF/rippled/pull/4789#pullrequestreview-1771165140]. This field accepts UNIX time instead of Ripple time because it must integrate with third party systems that may not measure time in Ripple time.
- fixPreviousTxnID, fixAMMv1_1, and fixEmptyDID went live.
- Added PreviousTxnID, PreviousTxnLgrSeq fields to ledger entry types
that had them added by the fixPreviousTxnID amendment.
- Updated ledger entry examples for several of those entry types.
- Documented DirectoryNode flags for NFT offer directories. (These were
missing, but have been around since NFTs went live.)
- Add new amendments from rippled 2.2.0
- Update badge syntax for main amendments table
- Update callout/admonition syntax
- Fix some incorrect information about default votes;
add "default vote: no" for removed obsolete amendments.
- Put some amendments back in the correct alphabetical order.
Co-authored by: Rome Reginelli <rome@ripple.com>, pdp2121 <71317875+pdp2121@users.noreply.github.com>
fix file names + small styling
fix top nav link
update nav list
fix security card and margin
add featured projects + fix margins
add related articles
update link and light mode
mobile view
add prev next buttons
small styling fixes
add unique key & zindex
Update docs/use-cases/tokenization/index.page.tsx
Update docs/use-cases/tokenization/index.page.tsx
Update docs/use-cases/tokenization/index.page.tsx
Update docs/use-cases/tokenization/index.page.tsx
Update styles/_use-cases.scss
Update styles/light/_light-theme.scss
add sidebar children back + styling changes
Fix tokenization frontmatter & security links
Add link from Tokenization to NTTs page
- Update with the actual min bid formula used
- Change formulas to use pseudo-code characters instead of math symbols
which can be hard to read (for example ÷ looks like +, ⁶⁰ is small and
hard to see, etc.)
- Update callout syntax for Redocly
- Slightly restructure auction slot section to emphasize the "why"
first
Our guidelines suggest adding a date when using the badge markdoc
component, but until now the component's schema didn't have a defintion
for the date parameter, so it was reporting errors.
The date doesn't affect how the badge is displayed on the site, but
we can use it to see when a 'New in' badge is old enough to no longer be
relevant (typically >2yrs) so we can remove it.
Adds single sentence which addresses case when user bids on Pool which has not Trading fee yet set.
For reference this is the transaction on XRPL Mainnet: A3A278DEEF3C5E06126526F948F31436BDDD96E61779E2E7A55090270017BD89
The font hierarchy is a little complicated between the _content.scss,
_font.scss, and Redocly theme styles, but this at least aligns the
Redocly theme variables with the MD content styling.
- Display author metadata on landing page
- Remove unused Gateway Bulletins category
- Push category selector down so it doesn't get partly buried under the
top nav & Apex banner
- Remove blog-specific footer. (See also: #2501, #2503)
- Fix markup that was invalidly reusing the same HTML ID for multiple
elements.
- Use existing chips for blog categories instead of having separate
styles for blog chips. This fixes some issues where the contrast of
the blog category chips was not meeting WCAG contrast standards.
- Update yellow chip in light mode to meet WCAG AAA contrast standard.
- Use the extended name in the visible page title. The SEO metadata
field automatically detects and matches this, so we don't need to
have a separate instance of the long title that can get out of sync
in the frontmatter.
- Use the short name (Tutorials) in the top nav. (The previous commit
changed the sidebar to use the short name.)
- Update docs links for all methods.
- Add some missing methods.
- Add an icon for Clio-specific methods.
- Move the long list of ledger_entry examples below other types so those
ones are not as buried.
- Remove unused old JS files.
- Make method list sidebar self-scrolling like docs TOC sidebar, so that
links to methods lower in the list don't scroll the main UI up off the
visible part of the page.
- Fix#2470.
- Fix a broken 'try it' link on the amm_info page that was causing an
error page to display when clicked.
- Change transaction-results/transaction-results/ to not repeat itself,
adding a redirect from the old URL.
- Fix Japanese localization of 'tasks' not being updated to 'how-tos'.
(Translated pages in this subfolder were not being shown as translated
due to the mismatch.)
- Fix unparsed `[base58][]` link in addresses snippet.
Now that Clio 2.1.0 has been released, we want to make sure this info is updated in the api methods.
Ports changes made in this draft [PR](https://github.com/XRPLF/xrpl-dev-portal/pull/2337).
I will close that draft once this is merged.
For better URLs, the content folder has been renamed 'docs' and all
other files have been moved up a level. Also, non-docs images have been
moved to the static folder at the top level where they belong.
Many relative paths had to be fixed to make this work.
- Fix unique key warnings on Dev Tools and Docs pages
- Fix active code tab colors in light mode
- Fix dev tools padding
- Fix dev tools cards in light mode
- Fix tx sender sidebar in light mode
- Fix domain verifier example code in light mode
- Move docs graphics to appropriate place
- Fix spacing of header anchors
- Fix display of card grids in md
- Fix display of badges
- Fix theme-aware diagram coloring
- Fix left table columns being line-broken too aggressively
* Step 1 to migrate the blog - Add blog pages from the dev-blog repo
* Add blog-specific sidebar (& update contents)
* Add new dev reflections blog post from 01-23-2024
* Blog migration: fix markdoc errors and broken links
* Remove community pages from the sidebar
---------
Co-authored-by: mDuo13 <mduo13@gmail.com>
Attempt migrating interactive tutorial again
Migrate interactive tutorial snippet syntax
Interactive tutorials: partially migrate send-xrp, no-freeze to new syntax
Fix Send XRP interactive tutorial
Interactive tutorials: fixes for Redocly incl. localization challenges
Interactive tutorials: switch defaultValue back to value in anticipation of Redocly bugfix
Fix document.ready→window.onRouteChange, cyclers, etc. in interactive
tutorials.
Recreate branch from base, add react-query-params, fix permalinks, fix sidebar
use correct params library and upgrade redocly.
Fix command text not working with permalink and move more modal logic out of main component.
Moved more connection selection logic to connection modal
Removed many `data-*` attributes previously used by bootstrap modal css
Created a shared modal component which removed 38 lines.
WS Tool: Fix Link import
fix UL error
toggle CurlModal to show/hide on button clicks
resolve error: <div> cannot appear as a descendant of <p>
remove <span>
WS tool: sidebar fixes
Add baseline html
Add script tags
WIP fetchWallet
Make basic page with account step 1 work
Add decodeHex and helpers to update logs
Add fetchFile to access toml from domain
Copy over code & comment out migrated pieces
Add toml parsing
WIP: Add types and uncomment new code
Update the parseToml function to share code
Mostly migrate the validateDomain function
Fix bug by using for instead of foreach
Clean up code part 1
Refactor into separate files
Translate everything
Componentize the buttons
Split out code into separate files
Update package-lock
Fix spacing and uncomment code
Fix indentation
Fix direct import of xrpl
Fix import
cleaned up log entry handling to not build an array of elements
moved to resource folder and update css.
Move shared components and fix small errors
Move file and update sidebars
Fix slow load of long list of addresses
toml checker - sidebar/width fixes
Differences between original:
- react18-json-view used for responses
- cleaned up markup for expand and collapse
Original work on this was done by @khancode
Co-authored-by: Omar Khan <khancodegt@gmail.com>
Fix RPC sidebar and width
adds events page, updates convert-template script
adds proper filter logic to events page, adds moment
converts history page
converts impact and xrpl-ledger-overview page
try getting animation on impact to work
converts xrp overview page and logic
adds contribute page, still needs typeform integration and animations
converts developer funding page
adds dev tools page
add missing image
adds code samples py conversion to js
adds hook to read current theme, adds animations to impact page
adds careers animations
adds correct animations for contribute page
adds light mode v of animations on contribute page
adds animations to uses page
adds modal logos and uses modal logic
completes uses page
more changes
Fix casing issues with use case files
fix grid issue on uses
The changes in this commit were auto-generated by running
tool/migrate.sh
Following this commit, the Dactyl build no longer works but the Redocly
build (mostly) should.
Add tool/migrate.sh as a one-stop conversion script for the whole repo.
This script's duties include:
- Changing all links from their old (.html) paths to new paths
- Converting most Dactyl-specific syntax to Redocly equivalents
- Generating Redocly sidebar and redirects YAML files
This script is meant to be run from the repo top. It replaces syntax
in-place. Unless this is the final migration phase, the results of
running the migration script should be committed in a separate commit
whose message starts with '[DROP]' so it can be re-run on the latest
version of the master branch during rebasing.
Many commits have been squashed into this one, including:
- Add tool/migrate_links.sh as a one-stop conversion script for links.
- Enable the update_links filter in dactyl config but make it inactive
unless you pass the appropriate vars
- Hack include_svg script to assume content/img instead of img
[FOLD] Migration scripting improvements:
- Roll scripting into all-in-one tool/migrate.sh
- Script moving/renaming Japanese snippets into @i18n
- Link replacment in snippets
- Handle links with query params
- Handle ref-links with anchors
- Remove some macro syntax that breaks Redocly
- Follow internal redirects in link replacement
- Handle links to some non-md pages
[FOLD] Migration script: handle more reflinks & imgs
[FOLD] tweak link migration
[FOLD] Fix substitution of reflinks
Add sidebar script
[FOLD] Fix link migration and whitespace noisiness
[FOLD] Link migration: auto-generate better link replacements
[FOLD] Convert badge syntax
[FOLD] Migration script: handle :not_enabled: syntax
[FOLD] Script generation of redirects
[FOLD] Migration script: make reusable common links
[FOLD] Fix common links code & conversion script comments
[FOLD] Add more non-md links
[FOLD] Fix filter_update_links syntax
[FOLD] Fix script's common links include placement
[FOLD] Migration script: update badge replacement to work w/ common-links
[FOLD] Fix ordering of converting common-links vs partials
[FOLD] Fix link substitution in common-links and fix trailing /index in redirects
Update convert-template
Add basic page
Add it to the sidebar
Fix a broken link
Fix translate usage and add linebreaks
Fix indents
Add basic sidebar
Port over init button logic
Migrate submit_and_notify and start dest addr
Get the payment button working
Componentize the Send XRP Payment button
Add basic escrow button
Componentize payment channel
Migrate Trust For
Migrate Send Issued Currency
Add partial payment progres bar logic
Use the component for the partial payment
Add support for escrow finish
Log transactions in sidebar
Debugging partial payment setup
Add support for changing destinationAddress
Finish adding bootstrap growl notifications
Use 'client' instead of 'api'
Move DestinationAddressInput to component and remove ids
Split the page into separate files
Remove the old files for this page
Update links
Add space
Add comment deprecating bootstrap-growl jquery
Fix typing errors
PR Comments Pt 1
Small PR fixes
Encapsulate isValidDestinationAddress
* Get basic HTML loading for faucet page
* Add xrpl.js implementation
* Add sidebar and fix throbber
* Add translates
* Try to format sidebar
* Fix formatting
* Support xrpl.js
* Fix links
* Comment out XRPLGuard for now
* Make AMM Devnet faucet work
* Improve readability
* Update all instances of link + fix topnav
* Remove unnecessary file
* Use a more current version of xrpl
* Add missing loader while keys are generating
* Type with xrpl and remove unnecessary script
* Use string interpolation instead of multiple trans
* Move faucets into a json file
* Remove the old faucet code
* Use xrpl-beta directly
* Use dropsToXRP
* Support hooks natively
* Remove AMM-Devnet
* Revert changes to link path
* Revert link changes pt 2
* Revert pt 3
* Use XRPLoader for loading icon
* Fix small mistakes
* Remove unnecessary changes
Script replacing include_code with code-snippet
Migration script: partials, some variables
Add variables to conversion script
draft repo-link component
Complete repo-link component
Migration script: handle github links
Draft include_svg→inline-svg (non-functional)
Currently doesn't work due to image path issues.
Also, captions and custom classes (for inlining) not implemented yet.
Conversion script: refactor & add code-page-name
Custom code-page-name component works around Markdoc limitation where
vars can't be used in `inline code` sections.
Migrate script: Handle more code includes correctly
Migration script: tabs and tabbed code samples
Child pages macro & conversion script
Adapted from 70cffa67ed
Migration script: update with some partial fixes
Migration script: callouts→admonitions
Fix auto-generation of index pages
Migration script: fix SVG migration
Migration scripting: fix code block prefixes & indentation
- Use the Redocly 0.66 feature for code block prefixes
- Update the script for converting indented code blocks to fences with
Roman's latest fixes (now uses 4 spaces per level, for consistency)
During migration, while we launch Redocly with -d content, the static
files need to be in content. Eventually, when we stop using -d, we need
to move the files again.
Previously:
/assets : static assets used by templates
/img : images used in documentation (mostly)
Now:
/content/static : static assets used by templates
/img : images used in documentation (mostly)
Eventually:
/static : static assets used by templates
/docs/img : images used in documentation
wip
fix links
fix 2 links
trim and add topics
Add checklist, rename sc subtopics
Fix internal links
Add DEX/AMM
Add graphics
reorg files
reorg/rename
Fix blurb
Remove old JA files
edits per review
review changes
rename output file name of index files to match the folder name
Update output file and parent filenames
add reusable links snippet
fix broken links
Update Ja file
Move path.md to same location in i18n folder
Revert naming for nft-collections page
Rename to match files in En and Ja
update links to reflect updated file name
Rename nft-auctions under Ja folder and update links throughout
Rename nftoken-authorized-minting and update links throughout
Fix links
Rename the nft-fixed-supply Ja file to match the reorg in English and update links
Move nft-reserve-requirements file in Ja and update links
Fix some more broken links
Fix more broken links by renaming html files back
Stablecoin reorg: fix various issues
Remove nfts_by_issuer method (unreleased) page
Remove redundant parent: attrs from config file
Fix syntax highlighting of Authorizing Another Minter js
Fix config/frontmatter errors
As part of the Redocly migration, I'm removing syntax that isn't
compatible with the new portal. In many of these cases, the existing
if/else statements weren't working as intended anyway because they
hadn't been updated after the files had been renamed.
In the case of the Client Libraries page, I've removed mention of
editing the page to contribute client libraries for now; when someone
adds guidelines (issue #2266) it would make sense to add a link to those
guidelines in that place instead.
This makes no difference to how the site is built under Dactyl (other
than where the "Edit Page" links go) but changes the URLs that will
be used for the pages after the migration to Redocly.
In addition to renaming index pages to index.md, I updated the style
guide to reflect the updated conventions, and moved a couple files that
were not in the correct folders for their place in the nav hierarchy.
Per a discussion on Mattermost, added stronger wording to the "Minimum Specifications" to clarify that they're only good enough for testing, not production use.
Part of IA and Redocly migration work. Create simple .md files to
represent the automatic index pages that previously only existed in
the dactyl-config.yml file. (The code used to do this is also part
of the commit but is, hopefully, no longer needed.)
Relating to IAv3 and Redocly migration work, this moves introduction
files to match their location in the IA, so that their "pretty" URLs
under Redocly will also match.
The new folder will be compatible with both Dactyl and Redocly when it
comes to loading the Japanese translation for a given page.
Snippets are not moved for now because importing them would require
more complex changes to the actual Markdown pages, and wouldn't be
cross-compatible anyway (Redocly uses slightly different 'partial'
rather than 'include' syntax.)
The Clawback page had some "in this specification" language that was copied from the XLS spec, and was confusing in the new location. This rewrite should clarify.
The type prefix is not part of the 20-byte AccountID, but it is used
when calculating both the checksum and the base58 address itself, so I
have updated the diagram accordingly.
Fixes#1405.
Using https would result in:
(node) UnhandledPromiseRejectionWarning: ValidationError: server URI must start with `wss://`, `ws://`, `wss+unix://`, or `ws+unix://`.
at new Client (index.js:88:19)
* adds new filter - info sessions, adds 3 new events
* adds new filter - info sessions, adds 3 new events
* adds south korea meetup img
* rm modified css file from PR
* Update template/page-events.html.jinja
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
* adds correct date order
---------
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
* Fix various style/template issues
- Add styles to allow fully invisible headers. These can be used to
support anchor links in translated pages, so we can move the link_subs
out of the dactyl-config.yml. Example in transaction-common-fields.md
- Upgrade jQuery to 3.7.1
- Add left nav to references landings for consistent navigation
- Add breadcrumbs template (previously used Dactyl built-in) which
throws an error if you specify a parent: that doesn't exist.
(Previously it would write a blank link; the link checker would
report this as an error, but it wasn't obvious what the cause was.)
- Fix#2014 (special case for code blocks nested in lists).
- Fix#2096.
- Remove excessive spacing between top nav and main content, and
re-align top of main contents in all 3 columns for docs pages.
- Reorganize _content.scss to be easier to read.
* Upgrade yarn packages (fix dependabot alerts) & rebuild CSS
* Fix NFT broken link in translation
* [ja] Properly fix NFT data link
* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity.
* Cancel escrow: fix notes
* Add draft of updated cancel-escrow.js.
* Update intro to escrows.
* Add Escrow Tutorial
* Minor corrections
* Fix headings, add HTML
* Update escrow docs
This commit re-creates f205a92db2 with
some adjustments:
- Omit the accidentally-created dir full of junk
- Fix some typos and one mistake in the Escrow limitations section
- Add a table to the EscrowCreate ref to clarify valid combos of fields.
* Concept info from send-a-time-held-escrow added to escrow.md
* IA: Move "Consensus Network" files
This re-creates some work from the original commit 56fffe0b9f
* Rewrite escrows article (re-created)
This commit re-creates relevant work from the following commits:
9a4a588f2b Update escrow.md context info
e1b017dc83 Remove references to using escrow for interledger payments.
* IA: Move "XRPL servers" files
This re-creates some work from original commit 7611979abf
* IA: move "production readiness" files.
Re-creates work from the following commit:
692438693a Move tutorials to concepts
* New intro articles
Original commit: 56fffe0b9f
* IA: Reorg account concepts
Re-creates some work from original commit 56fffe0b9f
* IA: reorg transaction concepts
Original commits:
9d4eff9940 WIP - reorg accounts
7611979abf WIP dir. reorg
* IA: reorg consensus concepts
Original commit: 56fffe0b9f
* IA: Reorg ledger docs
Original commit: 56fffe0b9f
- Rephrased some details of the section
* IA: rename issuing/operational addresses page
Original commit: 56fffe0b9f
* Moving use cases
* Fleshing out Use Cases
Note, the dactyl-config.yml file has not been fully updated.
* Clean up checks conceptual info.
* Remove redundant checks use case section
Original commit: 3c29e9c05e
* IA: move Dex under tokens
Original commit: d08b3ba7d7
* Touch up stablecoin issuer use case (#1856)
* Consolidate stablecoin use case
* Stablecoin issuer: cleanup progress through sending
* Stablecoin issuer: reorg second half
(Note: the dactyl-config.yml is not fully reconciled yet)
* Move rippled and clio tutorials into infrastructure
* Remove link to checks amendement.
* Add note to account_objects.md about commandline interface type field.
* Merge expiration case with lifecycle section.
* Interoperability Use Cases
* Add graphics to intro
* Move escrow use cases to dedicated page.
* Update use case page intros and corresponding concept info.
* Clarify meaning of direct XRP payments.
* Intro link updates
* Payment use cases
* Remove some unnecessary links in transactions section
Original commit: e6fcf4a4dc
* Link cleanup in Tokens section
Original commit: 9588dd5e70
* Touch up 'Configure Peering' section
Original commit: fc8f0990b8
* Clean up links in accounts section
Original commit: 3da5fde7a8
* Add NFT mkt use case
* p2p payments: edits to Wallets
* Clean up payments use cases
* Refine history description
* IA: use case cleanup
* IA: reconcile servers, ledgers sections
* IA: reconcile payment types, tx, tokens
* IA: reconcile accounts section
* IA: reconcile infra
* IA: Fix most broken links
* Full Docs Index: omit from sidebar
* IA: fix up most broken links
* fix Absolute path link to internal content
* Quick updates to Software Ecosystem
* Remove some absolute links to internal resources
* Fix remaining broken links in JA target
* Contributing: tweak formatting
* Tutorials: fix some minor issues
* remove interop use cases
* remove intro image and personal references to dennis
* alphabetize-transaction-nav
* Remove unused files
* Add QS escrow tutorials
* IA: move ledgers, consensus protocol files around
* IA: update nav for new page hierarchy
* reordering of topics under new networks and servers top-nav
* Move "Naming" to "What is XRP?"
* Update dactyl-config.yml
Remove xrp.md from the TOC.
* Update list-xrp-as-an-exchange.md
Update link to what-is-xrp
* Update list-xrp-as-an-exchange.ja.md
Change link to what-is-xrp
* Update currency-formats.md
Change link to what-is-xrp
* Update currency-formats.ja.md
Change link to what-is-xrp
* Update cancel-an-expired-escrow.md
Change link to what-is-xrp
* Update paymentchannelfund.md
Change link to what-is-xml
* Update look-up-escrows.md
Change link to what-is-xrp
* Update tokens.md
change link to what-is-xrp
* Update use-payment-channels.md
* Update send-a-time-held-escrow.md
Update link to what-is-xml
* fix broken links
* Update parallel-networks.md
Change link to what-is-xml
* Update parallel-networks.ja.md
* Update invariant-checking.md
Remove link to xrp.html
* Update invariant-checking.ja.md
Remove link to xrp.html
* Update transaction-cost.md
Change link to what-is-xrp
* Update transaction-cost.ja.md
Change link to what-is-xrp
* Update send-a-conditionally-held-escrow.md
Change link to what-is-xrp
* Update stablecoin-issuer.md
Change link to what-is-xrp
* Update tokens.ja.md
Change link to what-is-xml
* Update autobridging.ja.md
Change link to what-is-xrp
* Update currency-formats.md
update text
* reorganize infrastructure nav section
* Update currency-formats.md
Try removing link altogether.
* Update currency-formats.ja.md
Remove link to what-is-xrp.html
* move commandline usage topic to infrastructure
* initial intro rewrite
* minor update to language
* IA.v3: rm Production Readiness
* Delete xrp.md
* Update xrp link in snippet
* Add redirect for old xrp.html URL
* Small edits to 'What is XRP?' article
* Add missing imgs
* XRP - copy edit per @DennisDawson
* restructure tutorials nav and pages
* fix broken links
* more broken link fixes
* Algo trading: 1st draft
* Algo trading: notes on taxes
* Algo trading: edits per review
* algo trading: fix broken link
* Ledger structure: rewrite for accuracy and clarity
* Update links to removed 'tree format' header
* Ledger Structure: Update diagrams
* Re-gen CSS for ledger structure changes
* Ledger structure: edits per review
* IA.v3: fix broken NFT links introduced by rebase
* Desktop Wallet (py): update little stuff
* Update some capacity/storage details
* contribute doc nav update
* fix image link in create diagram page
* IAv3: Fix 'Ledgers' blurb
* Update full history requirements with details from community members
* add reviewer suggestions
* Edits per @trippled review
* Apply suggestions from peer review
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
* FH: reword file size limit note per review
* Update software ecosystem
* updates per review
* Minor tweaks to graphics
* fixTypos
* Update content/concepts/introduction/software-ecosystem.md
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
* Update content/concepts/introduction/software-ecosystem.md
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
* [JA] update AccountDelete cost
* custom transactors doc
* add doc to dactyl config
* [JA] fix NonFungibleTokensV1_1 amendment status
* [JA] update NFTokenOffer page
* Remove old, unused XRP article (#2039)
* add reviewer suggestions
* Add tooling to check for file/nav consistency
- From the repo top, run tool/check_file_consistency.py to look for
Markdown files that exist in the "content/" directory but aren't used
in the documentation.
- New "enforce_filenames" filter prints a warning to console when
building, if a file's path and filename don't match expectations
based on its place in the nav and top heading.
* File consistency checker: correctly handle filenames starting in _
* Remove unused old 'get started' and associated code
* Create Resources section & reorg some files
- Rename some files/folders based on their place in the nav
- Move a bunch of non-documentation stuff, and docs on contributing code
and/or docs to the new "Resources" section.
- Known issue: nav spills into a second row on page widths between
993px-1110px. To be fixed in a later CSS update, maybe along with
making the Resources dropdown multi-column.
* Fix#2078 code tab bug
CSS not built yet, to reduce merge conflicts. Won't have any effect
until that happens.
* fix Transaction JSON
* [JA] translate contributing contents
* fix contributing-to-documentation parent
* fix contribute-code blurb
* Top nav: add cols for Resources, fix broken links
* CSS: fix top nav overflows
* Fix broken link from redirect not in JA target
* Top nav: add Infra to article types
* Update contrib info & rename intro file
* [ja] Update link to suggested first page to translate
* [ja] fix contribute docs organization
* Run private network with docker tutorial (#2065)
* [NO-ISSUE] Run private network with docker tutorial
Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker.
Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it.
* Add minor link fixes and Japanese target
* Apply suggestions from code review
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
* Add link to ripple-docker-testnet setup scripts in See Also section
* Update repo URL
---------
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
* add intro gfx (#2036)
* add intro gfx
* Move graphic up
* Update some graphics with their revised versions
* Add updated version of the custodial vs non-custodial graphic
---------
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
* Update to reflect current UNL publishers
* [ja] update contributing
Co-authored-by: tequ <git@tequ.dev>
* Incorporate feedback on "What is XRP" page. (#2099)
* Add trademark info for XRP
* Revert section to previous state
* Fix broken link (#2101)
---------
Co-authored-by: Oliver Eggert <oeggert@ripple.com>
Co-authored-by: ddawson <dennis.s.dawson@gmail.com>
Co-authored-by: Maria Shodunke <mshodunke@ripple.com>
Co-authored-by: tequ <git@tequ.dev>
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: develoQ <develoQ.jp@gmail.com>
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
* Group by amendments on production, in development, and removed
* Update table for amendments in development
* Revise sections and cross-link topics
* Add amendment ID for AMM
* Add amendment ID for Hooks
* Move OwnerPaysFee to in-development section based on status
* fix broken link
* Update amendment status to be current
* Incorporate peer edit feedback
* Incorporate review feedback
* Apply suggestions from code review
Co-authored-by: Rome Reginelli <rome@ripple.com>
* Apply more suggestions from code review
Co-authored-by: Rome Reginelli <rome@ripple.com>
---------
Co-authored-by: Rome Reginelli <rome@ripple.com>
- Clarify that the sender of any Payment can enable the Partial Payment flag (it's not something that recipients control).
- Avoid burying the lede. Remind people to use delivered_amount. It can't be repeated too much.
- Clarify that the transaction cost is separate from the Amount.
The description of "limit" field will need to be changed for many of the API's to help clarify that values below 10 will be set to 10 and values above 400 will be set to 400. More information can be found here: https://github.com/XRPLF/xrpl-dev-portal/issues/1985
`mv` will rename the file (instead of moving it into a destination directory) if the destination directory does not exist. By providing the `/`, we are being explicit that we want the file to be moved.
If the earlier `mkdir` command was skipped or failed, we want `mv` to report an error, instead of silently renaming the key file to `keyrings`, which would not make sense.
Supplying a command to `gpg` prevents the warning which was previously shown in the gpg output.
- the "strict" parameter is now the default; only addresses are allowed
in the "account" field now (rippled PR#4404)
- now returns account_flags as a map of booleans (rippled PR#4459)
Minor style guideline to help avoid problems with broken links when pages are translated (resulting in the h1 anchor being different even though the page is the same).
The tutorial explains the right way to do things, but the example code has a file that is out of date. It shows CLIENT="wss://s.altnet.rippletest.net" which is missing the ":51233/" required to actually connect via websocket.
* Remove in-development docs for EVM sidechain and now obsolete content for federated sidechains dev preview
* Remove disclaimer note about EVM sidechain
* Remove references to sidechains which are in development
* Add redirects to deleted pages
* Incorporate feedback to comment out Issue Fields
* Fix broken links
When running against rippled locally, `ServerState.transitions` appears to be a string, and the documentation says it should be a string, so this PR updates the example to use a string instead of a number for that field. (I believe it used to be a number, but at some point changed)
* Add note that the EVM sidechains is a PoC and for development purposes only
* Changed sent to send in last sentence.
* Incorporate peer feedback
---------
Co-authored-by: Dennis Dawson <Dennis.s.dawson@gmail.com>
Remove outdated build instructions and add redirects to BUILD.md
@intelliot I'm going to merge this for now. If you see anything that needs to be changed, I can fix it in the `1100-release-docs` branch before commiting all the doc updates to the master branch.
* Add info about using Projects and Boards
to plan and track progress for content/documentation updates on xrpl.org.
* Add information about Kanban board
* Incorporate review feedback
* Incorporate feedback on wording for EVM sidechain
* Incorporate feedback
* Incorporate more feedback
* Update heading to reflect the assignment of Devnet tokens
* Add words from new features such as NFTs to the spell checker
* Add more proper nouns and general purpose words
* Add more proper nouns and general purpose words
* Update to use backticks
* Update proper nouns and generic words
* Fix style for words based on style checker report
* Style/spelling fixes
* Fix links broken by style/spelling updates
* More edits for style
* Finish updates to get style checker to pass
Co-authored-by: mDuo13 <mduo13@gmail.com>
Lathan in Mattermost called out that this line is confusing. I think this rewrite should clear up the confusion. (Note, I'm using "NFT" to get a head start on #1628.)
The note on the maximum value is not necessary because that's the actual hard max of a UInt32 type anyway.
"units of 1/100,000" is equivalent to "⅒ basis points" which is correct. This 10,000 number is a carry over from when it was basis points, not ⅒ thereof
Noah from the xrpl4j team noted that the STIssue definition used was wrong in the case of XRP, and the actual implementation has an optimization to drop the second 160 bits in the case where the first 160 bits are XRP.
- Update checkout, setup-python actions to latest versions
- Use head instead of cat so very long link reports don't fail the build
with an 'Argument list too long' error
- fix typo in serialization
- add STIssue type to type list in serialization
- more clearly mark things that need to be translated to Japanese
- Put AMMBid & AMMCreate transactions in alphabetical order
AMM object: some clarifications
AMM references: incomplete draft
AMM updates
AMM: add AMMBid, clarify more stuff
Docs for AMMBid transaction
AMM: more work on error codes
AMM: example transactions, related upates
Fix broken links
AMM: reflect naming updates
more AMMBid edits
Add amm_info API method
Add style for AMM label
AMM: more clarifications on tx, accounts
AMM references: Clean up draft
amm_info: reflect code updates
AMM: updates for the latest changes
AMM: update flags for Deposit/Withdraw
AMM: update JSON examples for latest code
Serialization: add STIssue type
STIssue: clarify definition with commas
- Add reporting mode specific fields
- Mark peers field as omitted from reporting mode
- Fix "external" gRPC link in server modes page
- Update "Configure gRPC" tutorial to better reflect current status of
gRPC in rippled
This commit fixes#1446.
Fixes#1553 by adding real examples from Mainnet of the NFTokenOffer
object type and NFTokenAcceptOffer transaction type (the offer entry is
no longer in the ledger because it was deleted when the sale was
completed, but you can look it up in ledger 75443623.
* Initial migration and edits for EVM Sidechains documentation
* Fix broken link
* Incorporate review feedback and fix indentaton for code snippets and images within steps
* Incorporate review feedback
* Fix indentation within steps
- fix NFTokenOffer JSON Type to use `Currency Amount` instead `object or string`
- incremental reserve to 2 XRP
- Corrected description of failure conditions at Direct Mode
-
- Add new amendments to the Known Amendments page.
(The URL for the 1.9.4 release notes is speculative; this release is
expected to happen "soon")
- Link the relevant API methods from the NFT concept page
- Rewrite some parts of the NFT concept page to be more concept-like and
less a list of reference details
- Update the status of the CryptoConditionsSuite amendment
Images whose content is defined in CSS have "data:," as their src
attribute because it's technically required and some tools may complain
about it missing, but the link checker complains about the data URI, so
this change makes the link checker skip these.
Also, the funding page is intended to go along with a Bounties program
that has not yet launched, so this disables it for now.
This job was added in an attempt to set up automatic deploys, but never
worked because of firewall settings on the machine that hosts the site.
Removing since the plan is to move to completely different
infrastructure by the end of the year.
I may be misunderstanding but the third bullet point under **Trust Lines and Issuing** states "Each account's balance (from its perspective on the trust line) can't go *above* that account's limit", but the section title in question is currently named **Going Below the Limit**. Should it be called **Going Above the Limit**?
The "tx_history" command is deprecated and intentionally not listed in the Websocket tool. This removes the broken "Try it!" link to use the WS tool for this method.
* Update some response field descriptions
* add response when client does not connect over localhost
* Add clarification on nested rpc and subscription objects as well
* Fix typo and incorporate feedback
* Update response fields
* Fix typo
* initial draft for nft_info command
* update request and response formats
* Incorporate review feedback
* Updated source URL and desc for is_burned
* Incorporate review feedback
* Incorporate additional review comments
* Incorporate peer edit comments
* Moving nft_info to new section
* Rename section to Clio methods
* Update dactyl-config.yml
Co-authored-by: Rome Reginelli <rome@ripple.com>
* Update content/references/http-websocket-apis/public-api-methods/clio-methods/nft_info.md
Co-authored-by: Rome Reginelli <rome@ripple.com>
* Update warning message location in the response as per code changes (#1462)
* Update warning level change in API response
* Move Clio APIs under one heading in the nav
* Update dactyl config file to group all Clio methods under one heading
* Fix file paths
* remove Clio from the nav title
* Add badge to note the version when this API was added
Co-authored-by: Rome Reginelli <rome@ripple.com>
Default vote behaviour in amendment voting. Copy pasted "the server uses a default vote which is defined in the source code" from the first paragraph in the Amendment Voting section.
by Ali:
c66be3e6cf/src/ripple/protocol/Protocol.h (L81)
1.2.1.1.1.2 TransferFee
The value specifies the fee, in tenths of a basis point, charged by the issuer for secondary sales of the token, if such sales are allowed at all. Valid values for this field are between 0 and 50,000 inclusive and a value of 1 is equivalent to 1/10 of a basis point or 0.001%, allowing transfer rates between 0% and 50%. A TransferFee of 50,000 corresponds to 50%.
Creds to Ali, Barry, nixerFmm, Nik B :)
Not a big deal, a mistake on my part in the original. Ideally, this will be more flexible in the future. I didn't realize these were hard-coded.
Co-authored-by: Rome Reginelli <rome@ripple.com>
Planning for the future, the requirement of 3 accounts on screen is specific to brokered sales. Other examples that do not require 3 accounts can be built off of the earlier examples. The brokered example is not necessarily in line with the future trajectory of the tutorial examples.
- Add example syntax for the 3 NFT methods.
- Add the ability to specify the network without the rest of a
permalink. NFT method "try it!" links can use this to have the tool
use the NFT-Devnet by default.
- Add the ability to mark methods as not enabled on the production
network.
When burning a token which has `lsfBurnable` enabled as the original minter, the `Owner` field is required to specify which NFTokenPages to search for the NFTokenID.
Here's the original issue which prompted this discovery: https://github.com/XRPLF/xrpl.js/issues/1947
* Decentralized Exchange concept article
1st draft
* DEX: example trade diagram, offers rewording
* Offers: more rewriting/updates
* OfferCreate: Add error cases + other updates
* Known Amendments: fix tecEXPIRED, DepositPreauth
- tecEXPIRED was initially attached to the Checks amendment but got
moved to DepositPreauth before either became released. The docs weren't
previously updated to reflect this change
- A change to the snippets caused the DepositPreauth amendment reference
link to get overwritten so the table links to the feature page rather than the
amendment description. Special cases this one link.
* OfferCreate error cases: switch to table
* DEX/Offers: edits per review
Feedback on the "Issue a Fungible Token" tutorial mentioned that the example there sets multiple flags using a combination of asf and tf flags, but the wording here says tf flags are discouraged. That's confusing, and not really accurate: there's nothing wrong with using tf flags where applicable; it's just that the AccountSet transaction type started running out of unique bits for tf flags, so newer settings only have asf flags.
Pages that exist in subfolders such as /tutorials/ are now OK, as
long as the add this line to the frontmatter:
prefix: "/"
This ensures that nav elements including top nav, sidebar, breadcrumbs,
all work, and that the appropriate JavaScript loads as intended.
* fix: link to new consensus mechanism explainer
* Update link for consistency
Similar update was made in PR#1306
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
This replaces the old wording of "issued currencies" and introduces
broader usage of the term "stablecoins" to more closely match the
terminology in use by the wider industry.
I've also added a draft "Common Misunderstandings about Freezes" page so
that the Freeze page doesn't have to protest quite so much, and written
a very brief word on tokens' use for community credit.
This commit only covers the Concepts section, in English, and likely
leaves some links to the old URLs for the renamed pages.
* Update consensus-principles-and-rules.md
youtube link does'nt work
* Updated link to XRPL Consensus Mechanism video
* Update consensus video link
Use consensus video in XRPL Foundation's playlist
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: Rome Reginelli <mduo13@gmail.com>
The original link pointed to the XRPLF channel, updated the link to point to the actual playlist for the explainer videos so that they are easier to find when there is more content on the channel
- Tutorial docs through step 3 (inputting an account)
- New screenshots
- Minor code cleanup
- Fix the include_code filter to better handle indentation in Python
code
Update css to v6
Add videos to xrpl overview page
Update css to v6
Move video player up on screen
Adjust vid position and size
Fix expanded video sizing on more resolutions
- Add a flask icon warning that the functionality is not enabled on the
production network
- Fix default coloring of unassigned topic labels in light mode
- Make a landing page for the NFTs topic label
- Assign a color to the NFTs topic label
- Update mentions of Ubuntu 16.04 which is past end-of-life
- Fewer mentions of "rippled" name
- Remove $ from copy-pasteable commands
- Other small wording cleanup
- Move recommended specs first for people who skim
- Mention of automatic [node_size]
- No longer recommending RocksDB in any circumstance
- Reduced usage of the `rippled` name.
The description of the ticket had it backwards: the default value for No Ripple is the opposite of the Default Ripple value. (The actual behavior of the API is correct.)
Show the answer of the question if there is a hash fragment in the url. Suitable when sending url with id of question. Until now, the answer has not been shown.
The call to initiate a new wallet (through fundWallet) must not include parameters.
The previous version of the code gives error: ReferenceError: Cannot access 'test_wallet' before initialization
- Move JS code samples to JS folder (future-proofing for other
languages)
- Make "Freeze a Trust Line" tutorial interactive
- Add necessary functionality to interactive_tutorial helper JS
- Rework freeze a trust line tutorial/code sample to make an incoming
line from another address and make looking up trust lines a
full-fledged step
- Use reliable transaction submission methods where available
- Update text to describe the functions (esp. xrpl.js 2.0 stuff)
- Move Send XRP code samples to subfolders by language for consistency
with other tutorials
DestinationNode is listed in the parameter descriptions, but missing from sample code. I've added the entry, copying the OwnerNode value for now. I'm assuming that the value is a placeholder with the correct number of digits. If we can put in a more realistic value, that would probably be better.
Count the total number of interactive blocks and add this data to the
memo when sending transactions from interactive tutorials. This should
help track the completion rate of tutorials to better measure
effectiveness of the documentation.
- Removes lodash dependecy for web version
- Uses the new generateFaucetWallet() API method
- Make 'issue a token' code capable of running in-browser or in Node.js
without modification
- Make sample code node.js compatible (need to uncomment a few lines)
- Wire up interactive tutorial bits to actually run the relevant code
- Edit instructions slightly, add notes on Require Destination Tags
- Fix bugs in submit and verify helper function
- Tweak tutorial and placement of helper function
- Finish drafting sample code
- Put sample code into tutorial
- Removed "and the full ledger history on disk" because I don't think reserve requirements really reduce the size of the ledger history. (But I could be persuaded.) Transaction fees are the main way that ledger history is kept from growing excessively large.
- Top nav external links now open in a new tab as intended (not specific
to light mode)
- Consistently adjust opacity (not placement) of background images in
mobile; lighter in light mode for legibility.
- Add a subtle white "shadow" to eyebrow text in light mode to improve
legibility
- Fix focus styles for buttons & multicode tabs in light mode
- Make all buttons sized the same as primary buttons by default
- Fix typo that caused the "Reset" button on get-started to be unstyled
- Refactor theme switcher JS for simplicity.
- Fix issue with theme select icon not being visible in some cases.
- Update color of ✅ icons in interactive tutorial breadcrumbs
- Remove lots more unused files
- Make light mode toggles for Exchange and Wallet images
- Change layout for exchanges and wallets to work better at some screen
widths (between mobile and full 1080p)
- Fix light mode styles for some dev tools, carbon calculator, Edit
button, footer, etc.
- light mode icons, styles to switch them
- put all card graphics in the same place, removed unused ones
- template/style changes to use the card graphics consistently
- styled the light mode icon with new graphics & animation
- fixed mobile nav colors in light mode
- fixed side nav & dropdown hover colors in light mode
replacing --forward-port directions with --add-port
I'm new to firewalld, but I think the purpose of the [`--add-forward-port`](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-port_forwarding) is if it's served internally on a different port.
It very well may work as an open-port, maybe if there's a bridged network? (i.e., `docker`); I didn't have luck with it. I came to the page to see what port I needed to open with the command I'm presenting, but tried this approach first. I didn't get any peer connections. When I switched over to just opening the port as `51235/tcp` I quickly saw peers.
I am also new to running a node, and this particular one was running for around 2 weeks without peering which may have caused some difference.
I do also think this file could remain the same name as it's capturing it's intent.
Co-authored-by: Rome Reginelli <mduo13@gmail.com>
typo
Update content/tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.md
Update content/tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.md
`--add-port` not `--add-source-port`
add note for virtual firewall
Co-authored-by: Rome Reginelli <mduo13@gmail.com>
The Japanese translated version of xrpl.org has been falling behind.
Since it's a worse experience to see a page that's mostly untranslated,
which is the case for many of the new/updated page, and traffic to the
Japanese version of the site is <1% of total traffic, we are temporarily
disabling the language selector so that we don't direct people to the
largely-untranslated pages. The existing URLs, including pages that have
been fully translated, continue to work.
I was not able to install boost@1.75 using homebrew:
➜ brew install boost@1.75
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
Error: No available formula or cask with the name "boost@1.75".
==> Searching for a previously deleted formula (in the last month)...
Error: No previously deleted formula found.
==> Searching taps on GitHub...
Error: No formulae found in taps.
Option to stack on small devices.
Hide current table headers.
Add headers to rows.
Will need to add divs above tables to id each table for naming. Only did 2 tables in this as a test.
Other tables will hide headers completely and full width content.
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
Para obtener información sobre cómo contribuir a este repositorio, consulta [Contribute Documentation (XRPL.org)](https://xrpl.org/es_ES/contribute-documentation.html).
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.
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:
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:
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).
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.
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/fungible-tokens/transfer-fees.md) y el estado [congelación global](../tokens/fungible-tokens/freezes.md). Si la intitución financiera quiere la flexibilidad de manejar las configuraciones de distinta manera para cada token, la institución debe tener múltiples direcciones emisoras.
## Direcciones operacionales
Una dirección operacional es como una caja registradora. Realiza pagos en nombre de la institución para transferir tokens a clientes y socios. Para firmar transacciones automáticamente, la clave secreta para una dirección operacional debe ser alacenada en un servidor que está conectado a Internet. (La clave secreta puede estar almacenada encriptada, pero el servidor debe desencriptarla para firmar las transacciones.) Clientes y socios no crean ni deben crear trust lines a direcciones operacionales.
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)
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!
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.
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`.
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".
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).
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.
[{% 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:
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)
description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
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.
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`.
description: Acerca de eliminar una cuenta XRP Ledger.
labels:
- Cuentas
---
# Eliminar Cuentas
El dueño de una cuenta puede enviar una [transacción AccountDelete][] para eliminar la cuenta y las entradas relativas del ledger, enviando la mayoría del XRP en balance restante a otra cuenta. Para evitar la creación y eliminación de cuentas sin sentido, eliminar una cuenta requiere quemar una cantidad superior a la usual utilizada como [coste de transacción](../transactions/transaction-cost.md).
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 {% $env.PUBLIC_OWNER_RESERVE %}).
## 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 {% $env.PUBLIC_BASE_RESERVE %} de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos {% $env.PUBLIC_OWNER_RESERVE %} 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.
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 {% $env.PUBLIC_BASE_RESERVE %}). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
- Puede recibir XRP de [transacciones PaymentChannelClaim][] **únicamente en los siguientes casos**:
- El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
- El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_
- 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:
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/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 #}-->
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 {% $env.PUBLIC_BASE_RESERVE %}), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
## Ver también
- **Conceptos:**
- [Reservas](reserves.md)
- [Claves criptográficas](cryptographic-keys.md)
- [Cuentas emisoras y operacionales](account-types.md)
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.)
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 de propietario: **{% $env.PUBLIC_OWNER_RESERVE %}** 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 |
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)
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 {% $env.PUBLIC_OWNER_RESERVE %} 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 {% $env.PUBLIC_OWNER_RESERVE %} 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.
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)
description: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
labels:
- Blockchain
---
# Protecciones del consenso contra ataques y modos de fallo
El Protocolo de Consenso del XRP Ledger es un mecanismo de consenso _tolerante a fallos bizantinos_, lo que quiere decir que está diseñado para trabajar incluso si todo tipo de cosas salen mal: los participantes dependen de una red abierta poco confiable, y actores maliciosos pueden estar intentando controlar o interrumpir el sistema en un momento dado. Encima de eso, el conjunto de participantes en el Protocolo de Consenso del XRP Ledger no se conoce de antemano y puede cambiar con el tiempo.
Confirmar transacciones de una forma rápida mientras se mantiene las propiedades deseadas de la red es un desafío complejo, y es imposible construir un sistema perfecto. El Protocolo de Conenso del XRP Ledger está diseñado para funcionar lo mejor posible en la mayoría de las situaciones, y para fallar elegántemente en aquellas que no es posible.
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).
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. |
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`**.<ahref="#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 <ahref="#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. <ahref="#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 <ahref="#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)_.<ahref="#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 <ahref="#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).<ahref="#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 <ahref="#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 <ahref="#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 <ahref="#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 <ahref="#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
<ahref="#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.
<ahref="#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.
<ahref="#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.
<ahref="#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.
<ahref="#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.
<ahref="#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).
<ahref="#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.
<ahref="#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.
<ahref="#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.
<ahref="#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.
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. | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |
<!-- RESERVES_REMINDER: update recommendations in drops if reserves change -->
## 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 |
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.<aid="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.<aid="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.<aid="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.
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:
- 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)
- [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)
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/index.md).
2. Si la UNL negativa no está llena, cada servidor propone añadir **hasta 1** validador a la UNL negativa entre sus validadores confiables con una fiabilidad inferior al 50%.
3. Si la UNL negativa no está vacía, cada servidor propone eliminar **hasta 1** validador de la UNL negativa. Un servidor puede proponer eliminar un validador de la UNL negativa por dos motivos:
- Califica a ese validador con una fiabilidad > 80%.
- No tiene a ese validador en su UNL. (Si un validador deja de funcionar permanentemente, esta regla garantiza que se elimine de la UNL negativa en el ledger después de que se haya eliminado de las UNL configuradas de los servidores).
4. Si un cambio propuesto a la UNL negativa logra un consenso, el cambio se programa para entrar en vigencia en el siguiente flag ledger. Se puede programar hasta una adición y una eliminación de esta manera.
Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/index.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.
Los cambios programados y efectivos de la UNL negativa se rastrean en el [objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md) en los datos de estado del ledger.
### Límites de la UNL negativa
Para prevenir que la red se fragmente en dos o más subredes, la UNL negativa no puede reducir el requisito de cuórum a menos del 60% de las entradas de UNL _totales_. Para hacer cumplir esto, un servidor considera que la UNL negativa está "llena" si el número de validadores en la UNL negativa es del 25% (redondeado hacia abajo) del número de validadores en la UNL configurada del servidor. (El 25% se basa en el cálculo de que si se eliminan el 25% de los validadores, un consenso del 80% del 75% restante equivale al 60% del número original). Si un servidor considera que la UNL negativa está llena, no propondrá nuevas adiciones a la UNL negativa; pero, como siempre, el resultado final depende de lo que haga un consenso de validadores de confianza.
### Elección de múltiples validadores candidatos
Es posible que múltiples validadores sean candidatos para ser agregados a la UNL negativa, según el umbral de fiabilidad. Dado que como máximo se puede agregar un validador a la UNL negativa a la vez, los servidores deben elegir qué validador proponer agregar. Si hay múltiples candidatos, el servidor elige cuál proponer con el siguiente mecanismo:
1. Comienza con el hash del ledger de la versión anterior.
0. Toma la clave pública de cada validador candidato.
0. Cacula el valor de exclusión-o (XOR) del validador candidato y el hash del ledger padre.
0. Propón el validador con el resultado numéricamente más bajo de la operación XOR.
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%.)Duranteelprocesodeconsensoparaelledger_N_,muchosdelosvalidadoresrestantesproponenagregaraUnsteadyBenlaUNLnegativa.Lamociónpasamedianteuncuórumdealmenos31delosvalidadoresrestantes,yelledger_N_sevalidaconUnsteadyBprogramadoparaserdesactivado.
[{% inline-svg file="/docs/img/negative-unl-02.svg" /%}](/docs/img/negative-unl-02.svg "Diagrama: UnsteadyB está programado para desactivarse.")
[{% inline-svg file="/docs/img/negative-unl-04.svg" /%}](/docs/img/negative-unl-04.svg "Diagrama: UnsteadyB se desactiva y MissingA es programado para ser desactivado, también.")
[{% inline-svg file="/docs/img/negative-unl-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)
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)
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.
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.
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.
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
<aid="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)
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)
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 -->
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.
<aid="with-advisory-deletion"></a><!-- old anchor to this area -->
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).
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:
| Mainnet | Lanzamientos estables | _El_ [XRP Ledger](/about/), un libro contable criptográfico descentralizado impulsado por una red de servidores peer-to-peer y el hogar de [XRP](../../introduction/what-is-xrp.md). |
| Testnet | Lanzamientos estables | Una red de "universo alternativo" que actua como un campo de pruebas para el software construido en el XRP Ledger, sin impactar a los usuarios del XRP Ledger de producción y sin arriesgar dinero real. El [estado de enmienda](/resources/known-amendments.md) de Testnet está destinado a reflejar de cerca el de la Mainnet, aunque pueden ocurrir ligeras variaciones en el tiempo debido a la naturaleza impredecible de los sistemas descentralizados. |
| Devnet | Lanzamientos Beta | Una vista previa de las próximas atracciones, donde cambios inestables en el software principal de XRP Ledger se pueden probar. Los desarrolladores pueden utilizar esta altnet para interactuar y aprender sobre funcionalidades nuevas planficiadas para el XRP Ledger y enmiendas que no están habilitadas en la Mainnet. |
Cada altnet tiene su propia distribución separada de XRP de prueba, que se [regala gratis](/resources/dev-tools/xrp-faucets) a partes interesadas en experimentar con el XRP Ledger y desarrollar aplicaciones e integraciones. El XRP test no tiene valor en el mundo real y se pierde cuando la red se reinicia.
**Atención:** A diferencia de la Mainnet del XRP Ledger, las redes de prueba suelen ser _centralizadas_ y no hay garantías sobre la estabilidad y disponibilidad de estas redes. Han sido y siguen siendo utilizadas para probar diversas propiedades de la configuración del servidor, la topología de la red y el rendimiento de la red.
## Redes paralelas y consenso
El factor principal en determinar qué red sigue un servidor es su UNL configurado-la lista de validadores en los que confía para no colisionar. Cada servidor utiliza su UNL configurada para saber qué ledger aceptar como la verdad. Cuando diferentes grupos de consenso de instancias de `rippled` solo confían en otros miembros del mismo grupo, cada grupo continúa como una red paralela. Incluso si equipos maliciosos o malintencionados se conectan a ambas redes, el proceso de consenso evita la confusión siempre y cuando los miembros de cada red no estén configurados para confiar en miembros de otra red en exceso de su configuración de cuórum.
Ripple ejecuta los servidores principales en la Testnet y Devnet; también puedes [conectar tu propio servidor `rippled` para estas redes](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md). La Testnet y Devnet no utilizan conjuntos de validadores diversos y resistentes a la censura. Esto hace posible que Ripple reinicie la Testnet o Devnet en cualquier momento.
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/XRPLF/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:
<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 <ahref="ledger-history#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 <ahref="clustering">clustering</a>.</p></li>
<li><p>Te permite crear tantas conexiones directas de pares como desees. Tu servidor privado puede <ahref="ledger-history#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>
<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)
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 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 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.
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.
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`.
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)
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.
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:
- [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)
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).
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.
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:
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/).
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.
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/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`.
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 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.
### 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.
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` |
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)
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)
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).
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).
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)
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.
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.
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.
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)
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 [Xaman](https://Xaman.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)
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.
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.
- [_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.
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_.
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.
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.
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.
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" 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”).
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
<!--#{ using h4s for questions to keep them out of the right side nav (too cluttered when they display) and to provide appropriate text size for questions. #}-->
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.
