Las discusiones sobre XRPL se amplían mientras Schwartz explora las condiciones necesarias para un posible staking nativo

El diseño de larga data del XRP Ledger está recibiendo renovada atención tras los comentarios del Director de Tecnología (CTO) de Ripple, David "JoelKatz" Schwartz, quien afirmó que la próxima fase de la red podría requerir reexaminar cómo fluye el valor a través de su infraestructura.

La discusión surgió mientras desarrolladores y miembros de la comunidad examinan el papel en expansión del XRP Ledger (XRPL) debido al crecimiento continuo en aplicaciones de finanzas descentralizadas, la introducción de nuevos casos de uso de tokenización, y el reciente lanzamiento del primer fondo cotizado en bolsa (ETF) spot de XRP por Canary.

Las observaciones de Schwartz destacaron que las demandas emergentes en todo el ecosistema han provocado una conversación más amplia sobre si el staking nativo podría algún día integrarse en la red, a pesar de que la arquitectura de XRP es fundamentalmente diferente de los sistemas típicos de Proof of Stake (PoS).

Cambio en el pensamiento 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 de red también han cambiado. Según él, la actividad que involucra a XRP en plataformas DeFi, como Flare, MoreMarkets, Axelar y Doppler, junto con iniciativas en curso sobre programabilidad y potencial funcionalidad de Smart Contract, provocaron una reevaluación de qué capacidades nativas adicionales podrían eventualmente ser soportadas.

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 provocó sus comentarios. Según Akinyele, el lanzamiento del primer ETF spot de XRP y la llegada anticipada de más emisores señalan un cambio de dirección hacia un compromiso institucional más extenso con el activo, incluyendo dominios como fondos del mercado monetario y tesoros tokenizados.

Conceptos iniciales sobre Staking nativo

El CTO de Ripple aclaró que XRP difiere de las redes proof-of-stake en varias formas estructurales. Las comisiones por transacción en el XRPL se destruyen en lugar de distribuirse, el ledger está diseñado para mover cualquier activo rápidamente y a bajo costo, y la influencia del validador no está determinada por la propiedad del token. Afirmó que para que exista el staking nativo, la red requeriría tanto una fuente definida de recompensas de staking como un mecanismo para una distribución justa, lo que remodelaría cómo circula el valor dentro del ledger.

El miembro de la comunidad Vet respondió señalando que el staking en otras cadenas generalmente se emplea para determinar los productores de bloques, lo que plantea preguntas sobre cómo se aplicaría tal modelo al XRPL. En respuesta, Schwartz esbozó dos conceptos técnicos que él y otros colaboradores han examinado, mientras afirmaba que ambos siguen siendo poco probables de ser adoptados en el corto plazo.

Modelo de dos capas e incentivos de prueba ZK

En el primer concepto se utiliza un enfoque de consenso de dos capas. Según este modelo, las transiciones del ledger serían avanzadas por una capa interna de 16 validadores que serían elegidos a través de un mecanismo de staking.

El algoritmo de consenso actual de XRPL formaría una capa externa que regula las enmiendas, las directrices de tarifas y el funcionamiento adecuado de la capa interna. Según Schwartz, esta separación permitiría una mayor diversidad de validadores mientras se mantiene una progresión rápida del ledger mediante el uso de rondas más pequeñas y ligeras de validadores.

Un segundo concepto mantiene el mecanismo de consenso actual mientras reutiliza las comisiones por transacción para compensar las pruebas de conocimiento cero que verifican la ejecución de contratos inteligentes. Según el CTO de Ripple Schwartz, este enfoque reduciría la necesidad de que cada nodo ejecute cálculos complejos, trasladando los costos de verificación a la generación de pruebas ZK.

A medida que avanzaba la discusión, Vet planteó la cuestión de si la estructura de dos capas descargaría con éxito las tareas que requieren más recursos computacionales en un entorno incentivado, mientras se mantiene la lógica de consenso orientada a pagos actual.

Schwartz aclaró que el progreso del ledger sería gestionado por el protocolo interno en base a cada transición, con la capa externa supervisando. También afirmó que su diseño puede mejorar la resiliencia del sistema ya que el ledger solo se detendría cuando ambas capas cesen sus operaciones.

¿Quieres que tu proyecto esté frente a las mentes más brillantes de las criptomonedas? Preséntalo en nuestro próximo informe de la industria, donde los datos se encuentran con el impacto.