El diseño de larga data de XRP Ledger está recibiendo una atención renovada tras los comentarios del CTO de Ripple, David “JoelKatz” Schwartz, quien afirmó que la próxima etapa de la red podría requerir volver a examinar cómo fluye el valor a través de su infraestructura.
La discusión surgió mientras desarrolladores y miembros de la comunidad analizan el papel cada vez mayor de XRP Ledger (XRPL) debido al crecimiento continuo de las aplicaciones DeFi, la introducción de nuevos casos de uso de tokenización y el reciente lanzamiento del primer ETF spot de XRP por parte de Canary.
Los comentarios de Schwartz destacaron que las nuevas demandas dentro del ecosistema han impulsado un debate más amplio sobre la posible integración de staking nativo en la red, a pesar de la arquitectura fundamentalmente diferente de XRP respecto de los sistemas tradicionales de proof-of-stake.
Cambio de perspectiva sobre la funcionalidad de XRPL
Schwartz señaló que la industria blockchain ha cambiado desde el lanzamiento de XRPL en 2012. Afirmó que sus propias opiniones sobre gobernanza, consenso e incentivos en la red también han evolucionado. Según él, la actividad de XRP en plataformas DeFi, como Flare, MoreMarkets, Axelar y Doppler, junto con iniciativas en curso relacionadas con la programabilidad y la posible funcionalidad de smart contracts, motivaron una reevaluación de qué capacidades nativas adicionales podrían eventualmente ser soportadas.
XRP Ledger fue creado en 2012. El mundo blockchain ha cambiado muchas, muchas veces desde entonces.
Mis propias ideas sobre los modelos de gobernanza y consenso han evolucionado. He estado reflexionando sobre cómo se usa XRP en DeFi (tanto de manera orgánica con apps y protocolos como Flare,…
— David ‘JoelKatz’ Schwartz (@JoelKatz) 18 de noviembre de 2025
Sus comentarios siguen a una observación relacionada de J. Ayo Akinyele, quien citó el uso histórico de XRP en pagos, liquidación de activos tokenizados y operaciones de liquidez, lo que motivó sus declaraciones. Según Akinyele, el lanzamiento del primer ETF spot de XRP y la esperada llegada de más emisores señalan un cambio de rumbo hacia una mayor participación institucional con el activo, incluyendo ámbitos como fondos del mercado monetario y bonos tokenizados del tesoro.
Conceptos iniciales sobre staking nativo
El CTO de Ripple aclaró que XRP difiere de las redes proof-of-stake en varios aspectos estructurales. Las comisiones de transacción en XRPL se destruyen en lugar de distribuirse, el ledger está diseñado para mover cualquier activo de forma rápida y a bajo costo, y la influencia de los validadores no está determinada por la tenencia de tokens. Explicó que para que exista el staking nativo, la red requeriría tanto una fuente definida de recompensas como un mecanismo para su distribución justa, lo que transformaría la forma en que circula el valor dentro del ledger.
El miembro de la comunidad Vet respondió señalando que el staking en otras cadenas generalmente se utiliza para determinar los productores de bloques, lo que plantea dudas sobre cómo tal modelo se aplicaría en XRPL. En respuesta, Schwartz describió dos conceptos técnicos que él y otros colaboradores han examinado, aunque aclaró que es poco probable que ambos sean adoptados en el corto plazo.
Modelo de dos capas e incentivos ZK-Proof
En el primer concepto se utiliza un enfoque de consenso de dos capas. Según este modelo, las transiciones del ledger serían impulsadas por una capa interna de 16 validadores, quienes serían seleccionados mediante un mecanismo de staking.
El algoritmo de consenso actual de XRPL formaría una capa externa que regula enmiendas, directrices de comisiones y la funcionalidad adecuada de la capa interna. Según Schwartz, esta separación permitiría una mayor diversidad de validadores mientras se mantiene un progreso rápido del ledger usando rondas más pequeñas y ligeras de validadores.
Un segundo concepto mantiene el mecanismo de consenso actual y reutiliza las comisiones de transacción para compensar las pruebas de conocimiento cero (zero-knowledge proofs) que verifican la ejecución de smart contracts. Según el CTO de Ripple, Schwartz, este enfoque reduciría la necesidad de que cada nodo ejecute cálculos complejos, trasladando los costes de verificación a la generación de ZK-proofs.
A medida que avanzaba la discusión, Vet planteó la pregunta de si la estructura de dos capas lograría descargar tareas más intensivas en cómputo a un entorno incentivado, dejando intacta la lógica de consenso orientada a pagos actual.
Schwartz aclaró que el progreso del ledger sería gestionado por el protocolo interno en cada transición, con la capa externa supervisando. También afirmó que su diseño podría mejorar la resiliencia del sistema, ya que el ledger solo se detendría si ambas capas cesan sus operaciones.
Mejorá tu estrategia con mentoría + ideas diarias - 30 días de acceso gratuito a nuestro programa de trading
