El límite de emisión de los cuatro libros contables se respalda de formas distintas. El total de XRP está fijado en 100.000 millones de unidades y protegido por un invariante que impide crear monedas de la nada; el límite de 21 millones de Bitcoin está codificado en la fórmula de reducción a la mitad de la capa de consenso, con un recorte cada cuatro años establecido por el protocolo; Ethereum no tiene un límite fijo, y la comunidad ajusta mediante gobernanza su tasa anual de emisión; la tasa de inflación de Solana también es un parámetro sujeto a votación y converge gradualmente hacia el 1,5%. Lo que distingue a los cuatro es qué respalda el límite y quién detectaría primero un problema.
El problema de esta vez afectó precisamente al invariante de XRP. Al sumar las órdenes de la plataforma integrada, el motor de pagos usaba un contador de 64 bits; el «XRPNotCreated», añadido en 2017, también dependía de ese contador de 64 bits. Cuando el contador se desbordó, fallaron tanto la suma previa como el invariante posterior. El 25 de septiembre, RippleX lanzó el parche de emergencia xrpld 3.4.1, eludiendo el «voto de dos semanas con el 80 % de los validadores»: fue la primera vez que se hizo desde que se implementó el mecanismo.
Al seguir el rastro de este invariante, vi que comparte un contador de 64 bits con la lógica que suma las órdenes. El parche solo amplió el contador de 64 a 128 bits; no los separó en dos contadores. Se evitó el desbordamiento, pero el contador que respalda el límite y la suma de las operaciones siguen unidos. Si vuelve a ocurrir de otra forma, quizá no se resuelva de manera tan silenciosa.
El coste de provocar el fallo, en realidad, no es alto. Reproducirlo cuesta apenas unos cientos de XRP; no se han visto registros públicos de creación de monedas. En esta ronda también hubo un segundo cambio: el procesamiento por lotes fixBatchV1_2 se activó el 9 de octubre. El parche de emergencia eludió la votación habitual y separó la respuesta de seguridad de la gobernanza descentralizada: el equipo decide lo urgente; los validadores votan sobre lo que puede esperar.
El fallo estuvo en la base que respalda el límite, no en el límite mismo: este solo establece que no se puede superar una cantidad, pero el contador que lo respalda y la suma de las operaciones comparten el mismo punto vulnerable. Lo que falló nunca fue una cifra aislada, sino ese contador. Si más adelante otro libro contable con un contador independiente presenta un desbordamiento similar, o la oferta de XRP se desvía del límite de 100.000 millones, tendré que revisar por completo este análisis; mientras nada cambie en esos dos aspectos, lo mantendré tal cual. Para seguir este contador en el gráfico diario de XRP, Binance permite verlo con claridad: los datos diarios de la sección spot están a la vista y se pueden contrastar siguiendo las correcciones hacia atrás. Este texto recoge una opinión y no constituye asesoramiento de inversión.
$ZEC
$LUMIA
$ERA
#xrp账本修复可增发xrp的漏洞
El problema de esta vez afectó precisamente al invariante de XRP. Al sumar las órdenes de la plataforma integrada, el motor de pagos usaba un contador de 64 bits; el «XRPNotCreated», añadido en 2017, también dependía de ese contador de 64 bits. Cuando el contador se desbordó, fallaron tanto la suma previa como el invariante posterior. El 25 de septiembre, RippleX lanzó el parche de emergencia xrpld 3.4.1, eludiendo el «voto de dos semanas con el 80 % de los validadores»: fue la primera vez que se hizo desde que se implementó el mecanismo.
Al seguir el rastro de este invariante, vi que comparte un contador de 64 bits con la lógica que suma las órdenes. El parche solo amplió el contador de 64 a 128 bits; no los separó en dos contadores. Se evitó el desbordamiento, pero el contador que respalda el límite y la suma de las operaciones siguen unidos. Si vuelve a ocurrir de otra forma, quizá no se resuelva de manera tan silenciosa.
El coste de provocar el fallo, en realidad, no es alto. Reproducirlo cuesta apenas unos cientos de XRP; no se han visto registros públicos de creación de monedas. En esta ronda también hubo un segundo cambio: el procesamiento por lotes fixBatchV1_2 se activó el 9 de octubre. El parche de emergencia eludió la votación habitual y separó la respuesta de seguridad de la gobernanza descentralizada: el equipo decide lo urgente; los validadores votan sobre lo que puede esperar.
El fallo estuvo en la base que respalda el límite, no en el límite mismo: este solo establece que no se puede superar una cantidad, pero el contador que lo respalda y la suma de las operaciones comparten el mismo punto vulnerable. Lo que falló nunca fue una cifra aislada, sino ese contador. Si más adelante otro libro contable con un contador independiente presenta un desbordamiento similar, o la oferta de XRP se desvía del límite de 100.000 millones, tendré que revisar por completo este análisis; mientras nada cambie en esos dos aspectos, lo mantendré tal cual. Para seguir este contador en el gráfico diario de XRP, Binance permite verlo con claridad: los datos diarios de la sección spot están a la vista y se pueden contrastar siguiendo las correcciones hacia atrás. Este texto recoge una opinión y no constituye asesoramiento de inversión.
$ZEC
$LUMIA
$ERA
#xrp账本修复可增发xrp的漏洞