¿Cómo verifica la cadena de bloques los datos de los créditos de carbono? De la transparencia en cadena a la confianza en el mundo real

Última actualización 26/10/2026 09:55:15
Tiempo de lectura: 4m
Este artículo analiza el papel de la cadena de bloques en la verificación de datos de créditos de carbono, examina la relación entre la MRV, los datos del Internet de las cosas, los registros en cadena y la validación de créditos de carbono. También aborda, a través de ValueX Chain, desafíos como la falsificación de datos, el doble cómputo, los derechos tokenizados y la verificación entre sistemas, y analiza métodos para evaluar aplicaciones en entornos Web3.

La cadena de bloques se utiliza a menudo para mejorar la transparencia y la trazabilidad de los datos ambientales, pero que un registro sea transparente no significa que los datos sean intrínsecamente verídicos. En el caso de los créditos de carbono y otros activos ambientales, la verdadera credibilidad procede de una recopilación de datos completa, metodologías de cálculo, verificación independiente, gestión de registros y mecanismos de responsabilidad. La cadena de bloques puede proporcionar registros compartidos y herramientas de ejecución automatizada para estos procesos, pero no puede resolver por sí sola el problema de la veracidad de los datos del mundo real. Este artículo analiza, desde la perspectiva del flujo de trabajo de MRV, cómo los datos del Internet de las cosas entran en los sistemas en cadena, qué pueden y qué no pueden resolver los registros en cadena, y qué condiciones técnicas y empresariales deben considerarse al evaluar infraestructuras ambientales Web3 como ValueX Chain.

Puntos clave:

  • La cadena de bloques puede mejorar la trazabilidad de los registros de datos, pero no puede verificar automáticamente si la información del mundo real es verídica.

  • La credibilidad de MRV depende de los métodos de medición, las fuentes de datos, la verificación independiente y una asignación clara de responsabilidades.

  • Los dispositivos del Internet de las cosas, los oráculos, los contratos inteligentes y la cadena de bloques asumen funciones diferentes. Ningún componente individual puede garantizar la fiabilidad de todo el sistema.

  • Los atributos ambientales, el estado de registro y los derechos legales de los créditos de carbono deben estar claramente definidos. La tokenización no puede sustituir por sí sola la verificación ni el registro.

  • Al evaluar proyectos Web3 ambientales, conviene revisar conjuntamente la arquitectura técnica, la calidad de los datos, la adopción real y los mecanismos de economía de tokens.

Por qué la credibilidad de los datos de créditos de carbono es más importante que su registro en cadena

Las actividades relacionadas con créditos de carbono deben responder a una serie de preguntas concretas: si una determinada actividad ambiental ocurrió realmente, cómo se calculan las reducciones o eliminaciones de carbono, qué escenario de referencia se utiliza, quién recopila los datos correspondientes, quién emite las conclusiones de la verificación y si los atributos ambientales correspondientes ya se han registrado, transferido o retirado. Estas cuestiones no desaparecen automáticamente por utilizar una cadena de bloques. Aunque un dato se registre íntegramente en un libro mayor público, sigue siendo necesario saber de qué dispositivo procede, qué procesamiento ha recibido, qué método de cálculo se ha utilizado y si quien lo envió cuenta con la autorización correspondiente. Sin este contexto, el libro mayor quizá solo pueda demostrar que una cuenta envió un registro en un momento determinado, pero no que el evento real descrito en dicho registro haya ocurrido.

Los datos ambientales también presentan una clara especialización. Los distintos tipos de proyectos pueden requerir diferentes frecuencias de supervisión, modelos de cálculo y procedimientos de verificación. Por ejemplo, las emisiones del transporte pueden estar relacionadas con el consumo de combustible, las rutas y el peso de la carga. El almacenamiento de carbono en bosques puede requerir considerar la extensión del terreno, el tipo de vegetación, los estudios de muestreo y los cambios a largo plazo. Los datos relacionados con energías renovables pueden implicar la cantidad de electricidad generada, los intervalos temporales y la titularidad de los atributos ambientales. Si los límites y métodos utilizados por distintos proyectos no son coherentes, puede que los datos no sean directamente comparables, aunque todos puedan consultarse públicamente. Por ello, la credibilidad de los datos depende primero de que las normas aplicables y los métodos de cálculo sean claros, y después de que el sistema de registro pueda respaldar la trazabilidad y la auditoría.

Por esta razón, es necesario distinguir entre “datos trazables”, “datos verificados” y “resultados ambientales válidos”. La trazabilidad significa que se puede consultar el origen del registro, el historial de cambios y el proceso de tratamiento. La verificación significa que los datos pertinentes se han revisado conforme a determinados procedimientos. La validez de los resultados ambientales también implica que el proyecto cumpla las normas aplicables, que los límites de cálculo sean razonables y que las reducciones o eliminaciones de carbono cuenten con las pruebas correspondientes. Estos tres niveles están relacionados, pero no pueden sustituirse entre sí. Al evaluar aplicaciones ambientales de cadena de bloques, si solo se muestran registros de transacciones, hashes de datos o certificados en cadena sin explicar el proceso de verificación ni las normas aplicables, no es suficiente para demostrar que el sistema ha resuelto el problema de la credibilidad de los datos ambientales.

MRV e Internet de las cosas: cómo entran los datos reales en la cadena de bloques

MRV, es decir, medición, reporte y verificación, es un proceso importante para que los proyectos ambientales establezcan registros verificables. La fase de medición determina qué datos deben recopilarse y cómo hacerlo. La fase de reporte organiza los datos en registros que puedan revisarse e indica el alcance estadístico y la lógica de cálculo. La fase de verificación revisa las fuentes de datos, los métodos de cálculo y las pruebas relacionadas conforme a las reglas aplicables. Los requisitos de MRV pueden diferir entre proyectos y no deben simplificarse como una única función de software. Para que un sistema de cadena de bloques se integre en este proceso, primero debe aclarar qué datos proceden de dispositivos, cuáles provienen de registros manuales, cuáles se obtienen mediante cálculos de modelos y qué conclusiones deben ser confirmadas por terceros. Solo cuando la cadena de datos está claramente definida puede una auditoría posterior determinar si un registro basta para respaldar una declaración concreta.

Los dispositivos del Internet de las cosas pueden proporcionar una fuente continua de recopilación de datos ambientales. Por ejemplo, pueden registrar el consumo de combustible, la temperatura, el consumo energético u otros parámetros relacionados con actividades ambientales, y transmitir posteriormente la información a los sistemas empresariales mediante interfaces de datos. El sistema puede transformar formatos, detectar anomalías y realizar validaciones preliminares, además de decidir, según las reglas empresariales, qué información debe escribirse en la cadena de bloques. Dado que el almacenamiento y el cálculo en cadena también tienen costes, un diseño práctico no necesariamente requiere escribir cada dato bruto íntegramente en el libro mayor. Algunas arquitecturas pueden almacenar los archivos originales fuera de la cadena y registrar en ella resúmenes de datos, información temporal, credenciales de acceso o resultados de verificación. Este diseño puede reducir parte de la carga de almacenamiento, pero también implica que los auditores deben poder acceder a los datos fuera de la cadena y verificarlos. No pueden conocer si el contenido original es preciso basándose únicamente en su resumen en cadena.

En el proceso desde los dispositivos hasta la cadena de bloques también pueden intervenir oráculos u otras interfaces de datos. La función de un oráculo suele ser transmitir información externa a los contratos inteligentes para que estos puedan ejecutar reglas basadas en datos externos. Sin embargo, un oráculo no garantiza de forma inherente que los datos de entrada sean correctos: puede leer fuentes de datos sesgadas o verse afectado por fallos de interfaz, configuraciones de permisos o el comportamiento del proveedor de datos. Por ello, el sistema debe considerar la autenticación de la identidad de los dispositivos, la validación de la integridad de los datos, el tratamiento de marcas de tiempo, el etiquetado de datos anómalos, la gestión de permisos y la recuperación ante fallos. En el caso de las declaraciones ambientales, también conviene diferenciar entre comprobaciones automatizadas de datos y verificación independiente. Los programas automatizados pueden detectar errores de formato o valores anómalos, pero no necesariamente pueden determinar si un proyecto ambiental cumple todos los requisitos de cálculo y certificación.

Qué puede resolver la transparencia en cadena y qué no puede resolver

Una de las principales ventajas de la cadena de bloques es proporcionar a múltiples participantes un mecanismo de registro compartido y trazable. Según el diseño específico de la red y los contratos, el sistema puede registrar el momento de envío de los datos, las cuentas que realizan las operaciones, el estado de las transacciones y el historial de transferencia de los activos relacionados. Si las reglas de registro están bien diseñadas, los participantes pueden comprobar más fácilmente si se ha producido una operación, si un registro se ha actualizado y cómo ha cambiado el estado de un certificado digital dentro del sistema. Esto resulta especialmente relevante para la colaboración entre organizaciones, ya que distintas entidades pueden necesitar compartir ciertos registros sin querer que un único participante controle por sí solo todo el historial. La cadena de bloques también puede ejecutar mediante contratos inteligentes algunas reglas deterministas y reducir determinados pasos de procesamiento manual.

Sin embargo, la capacidad de registro de la cadena de bloques tiene límites claros. Puede facilitar el seguimiento de los datos que ya se han escrito, pero no puede confirmar automáticamente si los datos enviados corresponden a la realidad. Si la lectura de un sensor no es precisa, el sistema puede seguir escribiendo esa lectura incorrecta en el libro mayor. Si las hipótesis de un modelo de cálculo no son razonables, un contrato ejecutado automáticamente también puede producir resultados basados en datos de entrada erróneos. Aunque el hash de los datos coincida con el archivo original, esto solo demuestra que el archivo corresponde al resumen respectivo, no que el contenido del archivo sea verídico. El sistema sigue necesitando procesos fiables de recopilación de datos, métodos de cálculo claros y mecanismos adecuados de verificación externa para que los registros en cadena formen parte de una cadena de pruebas fiable.

Otro límite se relaciona con la privacidad y los secretos comerciales. Los proyectos ambientales pueden incluir datos operativos empresariales, información de la cadena de suministro o datos relacionados con personas, y no todos los datos brutos son adecuados para almacenarse públicamente. Los registros permanentes en cadenas públicas también plantean desafíos en materia de corrección de datos y gestión de la privacidad. Por tanto, una arquitectura práctica debe equilibrar la auditabilidad y la protección de los datos. Por ejemplo, puede publicar solo la información de prueba necesaria, conservar los datos sensibles en un entorno controlado y definir claramente quién tiene derecho a acceder, actualizar o verificar los materiales originales. Estos diseños también deben someterse a evaluaciones de seguridad y cumplimiento normativo. No debe asumirse simplemente que unos datos son más fiables cuanto más públicos sean, ni inferirse que necesariamente cumplen todos los requisitos de auditoría porque estén cifrados o resumidos.

Qué puede resolver la transparencia en cadena y qué no puede resolver

Tokenización de créditos de carbono y doble contabilización: la transparencia de los registros no equivale a derechos claros

La tokenización de créditos de carbono suele referirse al uso de tokens de cadena de bloques u otros certificados digitales para representar algún tipo de registro, activo o derecho relacionado con créditos de carbono. Sin embargo, al analizar un proyecto concreto, es necesario aclarar la relación entre el token y el crédito de carbono subyacente. Un token puede representar un crédito de carbono registrado, pero también puede limitarse a registrar determinados requisitos de participación, comprobantes de transacción u otros derechos relacionados con proyectos ambientales. Los efectos legales y las implicaciones económicas de estas estructuras no son iguales. Deben verificarse cuestiones como si el crédito de carbono subyacente existe realmente, si se ha verificado y registrado conforme a las normas correspondientes, qué derechos concretos tiene el titular del token y cómo se trata el estado del token cuando el activo subyacente se transfiere, se retira o es objeto de una disputa.

La doble contabilización es uno de los problemas que los sistemas de activos ambientales deben abordar con rigor. Si un mismo resultado de reducción de emisiones se registra repetidamente en varios sistemas de registro, o si un mismo atributo ambiental se reclama más de una vez, los participantes del mercado podrían formarse una percepción errónea del beneficio ambiental real. La cadena de bloques puede ayudar a rastrear la creación, transferencia y cambios de estado de los certificados dentro de un sistema, pero si no existen reglas de identificación unificadas ni mecanismos de sincronización de estado entre varios sistemas, un único libro mayor no puede impedir automáticamente la doble contabilización entre sistemas. Por tanto, el sistema debe definir claramente métodos de identificación únicos, información de registro subyacente, reglas de transferencia y procesos de retiro, así como conectarlos con los mecanismos de registro o verificación aplicables. La lógica técnica de prevención de duplicados debe coordinarse con los procesos institucionales y empresariales.

La liquidez de un activo tampoco puede sustituir la verificación de derechos. Un token puede negociarse en el mercado secundario, pero una actividad de negociación elevada no demuestra la calidad del activo subyacente ni garantiza que el titular del token pueda obtener los derechos correspondientes según lo previsto. El precio de mercado puede verse afectado por factores como la liquidez, la oferta y la demanda, la narrativa del proyecto y los mecanismos de negociación. La validez del crédito de carbono subyacente debe seguir evaluándose conforme a sus normas aplicables, registros de verificación y estado de registro. Si un proyecto no puede explicar claramente la correspondencia entre un token y el activo ambiental subyacente, incluso si las transferencias en cadena son transparentes y los contratos funcionan correctamente, no basta para demostrar que el token incorpora derechos ambientales claramente definidos. Por ello, la digitalización de activos ambientales debe considerar simultáneamente los registros técnicos, la identificación de los activos y la estructura de derechos. No debe evaluarse la credibilidad de un proyecto únicamente en función de si el token puede negociarse.

Cómo evaluar infraestructuras Web3 para la economía del carbono

Al evaluar este tipo de infraestructura, el primer paso es comprobar si la información técnica es suficientemente clara. La arquitectura de red, el entorno de ejecución de contratos inteligentes, los registros de transacciones, los mecanismos de nodos y validación, las configuraciones de permisos y los métodos de gestión de fallos pueden afectar a la fiabilidad del sistema. Los exploradores públicos de bloques pueden ofrecer una vía para observar las transacciones y la actividad de los bloques, pero el volumen de actividad por sí solo no explica completamente la seguridad de la red, el número de usuarios reales ni el valor empresarial. Una evaluación más completa también debe revisar la documentación técnica, el código de los contratos y la información de verificación, la continuidad operativa de la red y si las herramientas y aplicaciones relacionadas pueden reproducirse de forma independiente. En el caso de cadenas especializadas, también es necesario prestar atención a las conexiones entre cadenas, las dependencias del ecosistema y los mecanismos de gobernanza, ya que estos factores pueden afectar a la componibilidad de las aplicaciones y a los costes de mantenimiento a largo plazo.

El segundo paso es verificar el flujo de datos y las operaciones reales. Es necesario conocer de qué dispositivos o entidades proceden los datos, qué normas se utilizan para recopilarlos y calcularlos, quién realiza la verificación, cómo se corrigen los errores cuando se detectan y si los registros correspondientes pueden auditarse de forma independiente. Si un proyecto propone aplicaciones de seguimiento de créditos de carbono o validación de impacto ambiental, también conviene confirmar el estado de implementación real, los usuarios, el volumen de datos y las pruebas de verificación por terceros. Las descripciones de casos en el sitio web del proyecto pueden ayudar a comprender sus escenarios previstos, pero, si no están respaldadas por pruebas independientes, no es adecuado presentarlas directamente como resultados que ya han logrado una adopción generalizada o beneficios ambientales cuantificables. Para las aplicaciones ambientales, que los procesos empresariales funcionen realmente y que los datos puedan verificarse es más importante que limitarse a mostrar conceptos técnicos.

El tercer paso es evaluar el modelo económico y la función del token. Las comisiones de red, los mecanismos de incentivos y la estructura de suministro de tokens pueden afectar a la disposición de desarrolladores y usuarios para participar, pero el precio de un token no es un indicador directo de la calidad técnica ni del beneficio ambiental. Deben revisarse el uso específico del token, los requisitos de pago de comisiones, los planes de suministro y desbloqueo, los mecanismos de distribución de incentivos y si el uso de la red puede generar una demanda sostenida. También es necesario analizar si el proyecto puede seguir funcionando cuando hay pocos participantes en el mercado, disminuyen las recompensas o se contrae la liquidez del mercado. Si la operación a largo plazo de una aplicación depende en gran medida de la subida del precio del token o de la distribución continua de recompensas, sin una demanda empresarial real, puede enfrentarse a una disminución del uso cuando se debiliten los incentivos. El valor a largo plazo de una infraestructura depende, en última instancia, de que la fiabilidad técnica, la demanda empresarial, los flujos de datos verificables y los mecanismos económicos puedan sostenerse conjuntamente.

ValueX Chain y Gate: cómo distinguir la narrativa técnica de la información de mercado

ValueX Chain (VLX) se posiciona como infraestructura para una economía del carbono Web3, y la presentación oficial del proyecto en Gate también menciona la compatibilidad con EVM, MRV de datos ambientales y direcciones de aplicación relacionadas. Esto ofrece a los lectores un caso concreto para analizar cómo una cadena de bloques especializada puede atender actividades ambientales del mundo real. Sin embargo, el posicionamiento del proyecto no demuestra por sí solo que el proceso de verificación de datos haya alcanzado una determinada norma de validación independiente. Los investigadores deben seguir evaluando, elemento por elemento, sus capacidades y limitaciones según la documentación técnica, los registros de la cadena de bloques, las pruebas de aplicación real y las normas de verificación ambiental aplicables. La página de precio de VLX y la página de negociación de VLX/USDT en Gate pueden utilizarse para conocer la información de mercado del token, pero el precio y el volumen de negociación no sustituyen la verificación de la tecnología de red y las aplicaciones ambientales. Analizar por separado la capacidad técnica, la credibilidad de los datos reales y el rendimiento del mercado de criptoactivos permite comprender de forma más completa las oportunidades y los riesgos de las aplicaciones ambientales Web3.

Preguntas frecuentes

¿Puede la cadena de bloques verificar automáticamente que un crédito de carbono es real?

No. La cadena de bloques puede registrar el envío de datos, las transferencias de activos y los cambios de estado, pero no puede demostrar por sí sola que una actividad ambiental del mundo real haya ocurrido. La credibilidad de los créditos de carbono sigue dependiendo de las normas de cálculo aplicables, las fuentes de datos, los procedimientos de verificación y los mecanismos de registro.

¿Qué funciones asumen MRV y la cadena de bloques respectivamente?

MRV es el marco de procesos de medición, reporte y verificación, y se centra en cómo se recopilan, organizan y validan los datos ambientales. La cadena de bloques puede proporcionar registros trazables para determinados datos y operaciones, así como ejecutar reglas deterministas mediante contratos inteligentes. Ambos pueden combinarse, pero la cadena de bloques no puede sustituir la verificación profesional.

¿Por qué los datos ambientales necesitan el Internet de las cosas y oráculos?

Los dispositivos del Internet de las cosas pueden recopilar datos del mundo real, mientras que los oráculos u otras interfaces de datos pueden transmitir información fuera de la cadena a aplicaciones de cadena de bloques. Resuelven los problemas de recopilación y transmisión de datos, pero siguen siendo necesarios la autenticación de dispositivos, la validación de datos y la verificación independiente para reducir los riesgos de errores o manipulación.

¿La tokenización de créditos de carbono significa que el titular del token posee créditos de carbono?

No necesariamente. La relación legal y empresarial entre un token y el crédito de carbono subyacente depende del diseño específico y de la documentación relacionada. Es necesario verificar el activo subyacente, el estado de registro, los derechos del titular, las condiciones de transferencia y los mecanismos de retiro. No deben inferirse los derechos representados basándose únicamente en el nombre del token o en los registros en cadena.

¿Cómo determinar si un proyecto Web3 de economía del carbono tiene valor de aplicación real?

Puede evaluarse de forma integral desde dimensiones como la fiabilidad técnica, las fuentes y la verificación de datos, el estado de implementación real, la demanda de uso real y los mecanismos de economía de tokens. Los objetivos de diseño divulgados por el proyecto, la actividad pública en cadena y los resultados ambientales verificados de forma independiente pertenecen a distintos niveles de evidencia y deben evaluarse por separado.

Autor: Learn Team
Descargo de responsabilidad

* La información no pretende ser ni constituye un consejo financiero ni ninguna otra recomendación de ningún tipo ofrecida o respaldada por Gate.

* Este artículo no se puede reproducir, transmitir ni copiar sin hacer referencia a Gate. La contravención es una infracción de la Ley de derechos de autor y puede estar sujeta a acciones legales.

Artículos relacionados

Tokenómica de RENDER: suministro, incentivos y captura de valor
Principiante

Tokenómica de RENDER: suministro, incentivos y captura de valor

RENDER actúa como el token nativo de Render Network y permite realizar pagos por servicios descentralizados de renderizado con GPU, incentivos para nodos y la gobernanza de la red. La red aplica un modelo exclusivo de Equilibrio de Quemado-Acuñación (BME): cada pago por tarea quema tokens, y en cada época se acuñan nuevos tokens como recompensa para los participantes, lo que crea un equilibrio en el suministro determinado por la demanda.
27/03/2026 13:23:38
La aplicación de Render en IA: cómo el hashrate descentralizado impulsa la inteligencia artificial
Principiante

La aplicación de Render en IA: cómo el hashrate descentralizado impulsa la inteligencia artificial

Render destaca frente a las plataformas dedicadas únicamente a la potencia de hash de IA por su red de GPU, su mecanismo de validación de tareas y su modelo de incentivos basado en el token RENDER. Esta combinación permite que Render se adapte de manera natural y conserve flexibilidad en determinados contextos de IA, en particular para aplicaciones de IA que implican procesamiento gráfico.
27/03/2026 13:13:15
0x Protocol vs Uniswap: ¿Cómo se diferencian los protocolos de Libro de órdenes del modelo AMM?
Intermedio

0x Protocol vs Uniswap: ¿Cómo se diferencian los protocolos de Libro de órdenes del modelo AMM?

Tanto 0x Protocol como Uniswap están diseñados para el trading descentralizado de activos, pero utilizan mecanismos de negociación diferentes. 0x Protocol emplea una arquitectura de libro de órdenes off-chain con liquidación on-chain, agregando liquidez de diversas fuentes para ofrecer infraestructura de trading a billeteras y DEX. Uniswap, en cambio, utiliza el modelo de Creador de mercado automatizado (AMM), permitiendo intercambios de activos on-chain a través de pools de liquidez. La diferencia principal entre ambos es la organización de la liquidez. 0x Protocol se orienta a la agregación de órdenes y al enrutamiento eficiente de operaciones, lo que lo convierte en una solución óptima para proporcionar soporte de liquidez esencial a aplicaciones. Uniswap aprovecha los pools de liquidez para ofrecer servicios de intercambio directo a los usuarios, consolidándose como una plataforma robusta de ejecución de operaciones on-chain.
29/04/2026 03:48:20
¿Cuáles son los componentes principales del protocolo 0x? Análisis de la arquitectura de Relayer, Mesh y API
Principiante

¿Cuáles son los componentes principales del protocolo 0x? Análisis de la arquitectura de Relayer, Mesh y API

0x Protocol crea una infraestructura de trading descentralizado con componentes clave como Relayer, Mesh Network, 0x API y Exchange Proxy. Relayer gestiona la transmisión de órdenes off-chain, Mesh Network facilita el intercambio de órdenes, 0x API ofrece una interfaz unificada para ofertas de liquidez y Exchange Proxy coordina la ejecución de operaciones on-chain y el enrutamiento de liquidez. Estos elementos permiten una arquitectura que integra la propagación de órdenes off-chain y la liquidación de operaciones on-chain, de modo que Billeteras, DEX y aplicaciones DeFi pueden acceder a liquidez de múltiples fuentes mediante una única interfaz unificada.
29/04/2026 03:06:50
Análisis en profundidad de Audiera GameFi: cómo Dance-to-Earn integra la IA con los juegos de ritmo
Principiante

Análisis en profundidad de Audiera GameFi: cómo Dance-to-Earn integra la IA con los juegos de ritmo

¿Cómo evolucionó Audition en Audiera? Descubre cómo los juegos de ritmo han ido más allá del entretenimiento tradicional para convertirse en un ecosistema GameFi impulsado por IA y blockchain. Explora los cambios clave y la evolución del valor derivados de la integración de mecánicas Dance-to-Earn, la interacción social y la economía de creadores.
27/03/2026 14:34:16
Análisis exhaustivo de los casos de uso de las monedas de privacidad: cómo se utiliza Zcash en escenarios reales
Principiante

Análisis exhaustivo de los casos de uso de las monedas de privacidad: cómo se utiliza Zcash en escenarios reales

Las monedas de privacidad refuerzan la protección de datos en la Blockchain al ocultar el remitente, el receptor y la cantidad de la operación. Sus aplicaciones no se limitan a pagos anónimos: también abarcan operaciones comerciales, gestión de la seguridad de activos y protección de la privacidad de la identidad en distintos sectores. Zcash, una moneda de privacidad que emplea pruebas de conocimiento cero, incorpora un mecanismo de “privacidad selectiva” que permite a los usuarios elegir entre operaciones transparentes o privadas, adaptándose a diversas demandas reales.
09/04/2026 11:10:35