Transparencia de Donaciones con Blockchain: Prototipo de Trazabilidad

Calebe Ocanha Isacc Birer; Luciano Bérgamo

DOI: 10.22167/2675-6528-202602767

Artículo derivado de Trabajo de Fin de Curso (TCC), con contenido basado en el trabajo original del estudiante y adaptado al formato editorial de la Revista E&S con el apoyo de la herramienta ResumeAI, una solución de inteligencia artificial desarrollada por el Instituto Pecege para la síntesis y organización textual.

Resumen

La opacidad en los flujos financieros y la necesidad de mecanismos auditables para la gestión de donaciones motivaron el desarrollo de este estudio. Se investigó la eficacia de la tecnología blockchain y de los smart contracts en la promoción de la transparencia y la integridad de los registros digitales. El objetivo consistió en el desarrollo y validación de un prototipo funcional de trazabilidad operado en red distribuida. La metodología adoptada tiene naturaleza aplicada y carácter experimental. Se estructuró en etapas de levantamiento bibliográfico, implementación de código en lenguaje Solidity y pruebas operacionales en red pública de prueba (Sepolia) vía interfaz de la billetera digital Metamask. Los resultados evidenciaron la viabilidad técnica de la solución, validando el control de acceso basado en funciones y la conformidad lógica del quórum de aprobación. El análisis de las métricas de desempeño indicó la previsibilidad de los costos computacionales (gas) y la eficiencia de la Ethereum Virtual Machine en el procesamiento de reglas de gobernanza inmutables. Se verificó que la emisión de eventos on-chain permitió la reconstrucción integral del flujo decisorio, garantizando la auditabilidad permanente del sistema. Se demostró que la sustitución de la confianza institucional por pruebas criptográficas materializó la desintermediación financiera, proveyendo una herramienta eficaz para la gobernanza descentralizada y la visibilidad total de los recursos.

Palabras clave: Desintermediación; Ethereum; Gobernanza digital; Integridad de datos; Prueba criptográfica.

1. Introducción

La opacidad en los flujos financieros, particularmente en la gestión de donaciones, representa un desafío persistente que compromete la confianza y la transparencia. La necesidad de mecanismos auditables para asegurar la integridad de los recursos y la correcta rendición de cuentas ha impulsado la búsqueda de soluciones innovadoras. En este escenario, la transformación digital ha intensificado la adopción de sistemas que prometen mayor claridad y fiabilidad en las transacciones.

La tecnología blockchain, en su esencia, constituye un registro digital compartido y distribuido entre múltiples computadoras, garantizando que cada participante mantenga una copia idéntica del historial de transacciones. La información se agrupa en bloques, cada uno conteniendo un resumen criptográfico del bloque anterior, lo que asegura la inmutabilidad y la integridad temporal de los datos (Haber; Stornetta, 1991; Bayer; Haber; Stornetta, 1993; Merkle, 1988). Este modelo descentralizado reduce la dependencia de intermediarios, simplificando la verificación y la detección de fraudes. La propuesta inicial de la blockchain surgió con Nakamoto (2008) en el contexto de Bitcoin, popularizando el concepto de un libro mayor público, auditable e inmutable.

Complementariamente, el concepto de contratos inteligentes, introducido por Nick Szabo (1997), se refiere a mecanismos automáticos que simulan la lógica de los contratos tradicionales de forma digital. A través de código, las obligaciones y reglas pueden cumplirse de forma autónoma, eliminando la necesidad de una confianza total entre las partes. La plataforma Ethereum, creada por Buterin (2013), expandió el uso de esta tecnología más allá de las transacciones financieras simples, permitiendo la creación de contratos inteligentes de uso general y la ejecución de reglas de gobernanza inmutables (Antonopoulos; Wood, 2018).

A pesar de los avances teóricos y las diversas aplicaciones de la blockchain, su uso práctico para garantizar la trazabilidad y la transparencia en las donaciones aún es limitado. La mayoría de los estudios se centran en aspectos conceptuales, económicos o de seguridad, sin presentar evidencias concretas de su funcionalidad en prototipos operativos. Esta brecha impide la demostración real de los beneficios de integridad y auditabilidad que la tecnología puede ofrecer. La opacidad en los flujos financieros tradicionales y la dependencia de procesos manuales de rendición de cuentas en el tercer sector generan asimetría de información y desconfianza entre donantes e instituciones filantrópicas, evidenciando la necesidad de convertir reglas de gobernanza complejas en algoritmos computacionales seguros e inmutables.

Ante este escenario, la presente investigación se justifica por dos razones principales. Desde el punto de vista académico, existe una carencia de estudios detallados que expliquen las decisiones de implementación, la validación de resultados y las soluciones de trazabilidad basadas en blockchain, lo que dificulta la replicación y la comparación entre enfoques. En la esfera práctica, las organizaciones necesitan mecanismos auditables y descentralizados para aumentar la confianza y reducir la asimetría de información. Al desarrollar y evaluar un prototipo funcional, este estudio ofrece evidencias concretas de viabilidad, costo y rendimiento, contribuyendo al fortalecimiento tanto de la teoría como de la adopción consciente de esta tecnología.

La motivación para este diseño surge de la observación de demandas profesionales y de mercado latentes en la gestión de recursos del tercer sector. Así, el objetivo general de este estudio consiste en desarrollar y validar un prototipo funcional de trazabilidad para el flujo de donaciones digitales utilizando la tecnología blockchain y contratos inteligentes. La investigación se propone diseñar una lógica de gobernanza basada en firmas múltiples y logro de quórum mínimo, validando la integridad de las operaciones y analizando la viabilidad técnica de la solución por medio de métricas cuantitativas de consumo computacional en un entorno experimental de red distribuida.

2. Material y Métodos

La investigación desarrollada tiene naturaleza aplicada y carácter experimental, buscando crear, probar y evaluar un prototipo funcional de trazabilidad. Este enfoque fue seleccionado para comprobar la viabilidad técnica y operativa del modelo propuesto, permitiendo verificar el potencial de la herramienta para garantizar mayor transparencia y confianza en los registros digitales. La elección metodológica valoró el desarrollo de soluciones tecnológicas fundamentadas en conocimientos teóricos sólidos.

El estudio se estructuró en cinco etapas secuenciales. Inicialmente, se realizó una revisión bibliográfica para comprender los conceptos teóricos de blockchain, contratos inteligentes, trazabilidad y transparencia digital. Posteriormente, se definió el entorno de desarrollo, especificando los lenguajes y herramientas a utilizar en la implementación del prototipo.

La tercera etapa consistió en el modelado y la implementación del prototipo, que implicó la creación de los smart contracts y la interfaz de seguimiento. Posteriormente, en la cuarta etapa, se procedió a la simulación con datos ficticios en una red de pruebas, registrando transacciones para el seguimiento. Finalmente, la quinta etapa comprendió la recopilación y el análisis de los resultados, evaluando el rendimiento y la fiabilidad del sistema.

El entorno de desarrollo utilizó el lenguaje Solidity para la creación de los smart contracts y Remix IDE como plataforma de compilación e implementación. Las transacciones se realizaron en redes de prueba de Ethereum, como Sepolia Testnet o Ganache, accedidas a través de la billetera digital MetaMask. Este entorno permitió simular el funcionamiento de una red pública real sin exponer datos sensibles.

La verificación de los registros y transacciones se llevó a cabo a través de exploradores de bloques, como Etherscan, asegurando que todas las operaciones pudieran ser rastreadas y auditadas. Este enfoque técnico garantizó la observación del comportamiento del prototipo en un entorno distribuido, replicando las condiciones de una red blockchain en operación.

En relación con los aspectos éticos y legales, la investigación no empleó datos personales, sensibles o identificables. Toda la información introducida en el prototipo fue ficticia y genérica, garantizando la inexistencia de vínculo con individuos o instituciones reales. De esta forma, no fue necesaria la sumisión del proyecto a un Comité de Ética en Investigación (CEP/CONEP), y el estudio se alineó a las orientaciones institucionales y a la Ley General de Protección de Datos.

El análisis de los resultados se realizó mediante métricas técnicas, que permitieron evaluar la eficiencia y la viabilidad del prototipo. Se consideraron el tiempo medio de confirmación de transacción, el coste estimado de las transaciones, la fiabilidad de la trazabilidad y la facilidad de auditoría, esta última evaluada por la claridad y accesibilidad de los datos registrados.

El prototipo fue diseñado para demostrar la trazabilidad y la gobernanza del flujo digital de transacciones, registrando todas las etapas del proceso de toma de decisiones. Esto incluyó desde la creación de una solicitud de transacción hasta su eventual ejecución, con el objetivo de garantizar la transparencia y la posibilidad de auditoría completa del sistema.

Tras la implementación del contrato inteligente en un entorno de pruebas, este pasó a actuar como repositorio lógico del control. A continuación, se crearon solicitudes de transacciones, que contenían información esencial como la dirección de destino, el valor y la descripción de la finalidad. Cada solicitud permaneció registrada en el contrato hasta ser evaluada por los participantes autorizados, según reglas predefinidas.

La trazabilidad del prototipo se aseguró mediante el uso de eventos emitidos por el contrato durante su ejecución. Cada vez que se creaba, aprobaba o ejecutaba una solicitud, se registraba un evento, lo que permitía que estas acciones fueran seguidas por cualquier parte interesada a través de herramientas de auditoría de red.

Estos eventos funcionaron como un historial detallado del comportamiento del sistema, posibilitando la reconstrucción del flujo decisorio y la verificación de la conformidad de las transacciones con las reglas establecidas. De esta forma, el prototipo garantizó transparencia a nivel técnico, permitiendo una auditoría completa del proceso digital, incluso sin identificar a los usuarios del mundo real.

La función “crearPedido” se utilizó para registrar nuevas solicitudes de transacción en el contrato, definiendo parámetros como la dirección de destino, el valor nominal y la descripción. La función “aprobarPedido” fue ejecutada por diferentes direcciones autorizadas para registrar las firmas digitales necesarias. Este procedimiento fue crucial para alcanzar el quórum mínimo de aprobación.

Tras alcanzar el quórum mínimo de aprobación, la transacción pudo ser ejecutada a través de la función “ejecutarPedido”. Esta función procesó la liquidación financiera y actualizó el saldo del contrato en la red de pruebas, transfiriendo los recursos a la dirección de destino. La emisión del evento final “PedidoEjecutado” consolidó la transparencia del sistema.

El mecanismo de transparencia y auditoría del prototipo permitió el acceso directo a los registros internos del contrato. La función “getPedido”, definida con el modificador “view” en el lenguaje Solidity, aseguró la consulta pública, inmutable y gratuita de los datos almacenados en el ledger, sin necesidad de intermediarios.

3. Resultados y Discusión

Los resultados de la investigación evidenciaron la viabilidad técnica del prototipo de trazabilidad para donaciones digitales, fundamentado en tecnología blockchain y contratos inteligentes. El desarrollo y la validación del sistema demostraron la capacidad de registrar y auditar transacciones en un entorno distribuido, promoviendo la transparencia y la integridad de los datos. La implementación inicial del código en lenguaje Solidity, junto con la validación conceptual del flujo de ejecución del contrato en la plataforma Remix IDE, estableció la base para las pruebas operativas. Se observó que la configuración adecuada del entorno de prueba, incluyendo la disponibilidad de saldo en redes de prueba, fue crucial para la simulación precisa de las transacciones y la validación de los escenarios de uso propuestos.

El análisis crítico del desarrollo reveló un trade-off técnico significativo entre la validación lógica en simuladores locales y la implementación en redes de prueba externas, como Sepolia. Mientras que el entorno local de Remix IDE ofreció velocidad y depuración ágil, la transición a la red pública de pruebas expuso el prototipo a condiciones reales de latencia de propagación de bloques y sincronización entre nodos distribuidos, como teorizó Buterin (2013). Esta experiencia práctica confirmó que la validación en un entorno emulado externo es esencial para comprobar la resiliencia y la preparación del código en un escenario de producción distribuida, superando las limitaciones de las pruebas puramente sintácticas.

Se identificaron desafíos operacionales durante la fase experimental, principalmente la dependencia de infraestructuras de terceros para el mantenimiento de la cadena de pruebas. La obtención de moneda ficticia a través de “faucets” para ejecutar funciones de escritura en la red Sepolia frecuentemente enfrentó inestabilidad y limitaciones de cuota, impactando la cadencia de las pruebas. Además, la propia red de pruebas presentó picos de congestión o bifurcaciones, retardando el tiempo de confirmación de las transacciones. Estos factores resaltan que el desarrollo de soluciones descentralizadas exige una planificación rigurosa de recursos, ya que variables externas de infraestructura pueden escapar al control directo del desarrollador, como señalan Antonopoulos y Wood (2018).

Otro aspecto crítico de escalabilidad fue la volatilidad e imprevisibilidad de las tasas de red, conocidas como “gas”. Aunque la cantidad de unidades de gas consumidas por cada función del prototipo resultó determinista y predecible, el costo financiero real en la red principal (mainnet) de Ethereum fluctúa dinámicamente con la demanda global de espacio de bloque (Antonopoulos; Wood, 2018). La grabación de nuevos estados de memoria permanente (SSTORE) se tarifa con costos elevados para desalentar el almacenamiento ineficiente de datos. La optimización computacional basada en “hot slots” resultó en una economía del 31% en la segunda aprobación de una solicitud, demostrando un esfuerzo técnico de mitigación, pero sin eliminar el riesgo económico de la variación de las tasas de red.

Para viabilizar la aplicabilidad práctica a gran escala, las limitaciones económicas observadas sugieren la transición a redes de segunda capa (Layer 2) o cadenas laterales (sidechains). Estas estructuras procesan transacciones fuera de la cadena principal antes de consolidar los datos agregados de seguridad “on-chain”, reduciendo las tasas de ejecución y aumentando la escalabilidad del sistema de gobernanza colectiva, sin comprometer la inmutabilidad de los datos (Nakamoto, 2008). Adicionalmente, la custodia individual de las claves privadas asociadas a billeteras digitales, como MetaMask, representa un desafío humano y operativo, transfiriendo la responsabilidad de seguridad a los gestores de la institución. Errores operativos, como la pérdida de claves, pueden resultar en la pérdida irreversible de recursos, reforzando la necesidad de programas de gobernanza y capacitación de personal.

El prototipo fue diseñado para demostrar la trazabilidad y la gobernanza del flujo digital de transacciones, registrando todas las etapas del proceso de toma de decisiones, desde la creación de una solicitud hasta su ejecución. Tras la implementación del contrato inteligente en un entorno de pruebas, fue posible crear solicitudes de transacciones con información esencial como la dirección de destino, el valor y la descripción de la finalidad. Cada solicitud permaneció registrada en el contrato hasta ser evaluada por los participantes autorizados, siguiendo reglas predefinidas. El logro de un número mínimo de aprobaciones, establecido por el “quórum”, permitió la ejecución autónoma de la transacción, garantizando la transparencia y la auditabilidad del proceso.

La trazabilidad del prototipo se aseguró principalmente mediante la emisión de eventos por el contrato durante su ejecución. Cada vez que se creaba, aprobaba o ejecutaba una solicitud, se registraba un evento, lo que permitía que estas acciones fueran seguidas por cualquier parte interesada a través de herramientas de auditoría de red. Estos eventos funcionaron como un historial detallado del comportamiento del sistema, posibilitando la reconstrucción del flujo decisorio y la verificación de la conformidad de las transacciones con las reglas establecidas. De esta manera, el prototipo garantizó transparencia a nivel técnico, permitiendo la auditoría completa del proceso digital, incluso sin identificar a los usuarios del mundo real.

La validación técnica del código fuente fue un paso esencial. El proceso de compilación del smart contract en el entorno de desarrollo Remix IDE demostró que la estructura lógica era sintácticamente válida para la ejecución en la versión 0.8.20 del compilador. La confirmación del éxito, verificada por un indicador visual de éxito, aseguró que el código estaba listo para ser procesado por la Ethereum Virtual Machine (EVM). Esta validación técnica materializa los conceptos de Szabo (1997), que define smart contracts como mecanismos automáticos para simular contratos tradicionales, y Buterin (2013), que señala la compilación correcta como garantía de que el contrato actúa como un repositorio lógico inmutable y auditable, fundamental para la transparencia.

La implementación del smart contract en un entorno de pruebas, como se ilustra en el TCC original, demostró que el contrato fue debidamente instanciado y se convirtió en un elemento disponible para la interacción a través de llamadas a funciones. El panel lateral izquierdo de la interfaz de Remix IDE mostró campos estructurados para cada función, permitiendo la ejecución de comandos y la lectura de datos directamente en la red simulada. Esta etapa de instancia es fundamental para la materialización de la solución, ya que, al ser desplegado en la EVM, el código se convierte en un repositorio lógico inmutable y auditable. La transición del código estático a un contrato en ejecución “on-chain” refleja la ruptura del modelo de confianza centralizado, permitiendo sistemas “trustless”, donde la validez de las operaciones está garantizada por la verificación criptográfica de la red, y no por intermediarios (Nakamoto, 2008).

La función `crearPedido` fue responsable de registrar nuevas solicitudes de transacción en el contrato. Durante su ejecución, se definieron parámetros como la dirección de destino, el valor nominal y una descripción detallada, permitiendo el almacenamiento estructurado de la información para auditoría. La confirmación de la operación se observó en el panel lateral de gestión y en la terminal de salida del IDE, que reportó el retorno positivo de la función y la emisión del evento correspondiente. La implementación lógica de la función `crearPedido` utilizó el modificador `soloAprobador` para garantizar que solo direcciones autorizadas pudieran registrar nuevas demandas, y comandos `require` actuaron como cláusulas de barrera, impidiendo el procesamiento de datos inválidos, como direcciones nulas o valores zerados.

La instrucción `pedidos.push` aseguró la persistencia inmutable de los datos en la blockchain, mientras que el comando final `emit PedidoCriado` materializó el requisito de trazabilidad. Esta línea fue fundamental, ya que, como discutió Nakamoto (2008), la transparencia en sistemas distribuidos depende de la publicidad de los registros. Al integrar esta regla de gobernanza directamente en el código, el prototipo concretó la visión de Szabo (1997) sobre la automatización contractual, reduciendo la asimetría de información entre donantes y la organización a través de registros digitales permanentes y auditables.

La operacionalización de la gobernanza distribuida fue detallada por la función `aprovarPedido`, que implementa la lógica de firmas múltiples (multisig), garantizando que la movimentación de recursos dependa del consenso entre los participantes autorizados. El comando `require` actuó como un bloqueo de seguridad, impidiendo que se accediera a una solicitud inexistente o que un participante votara dos veces en el mismo registro. La línea final `emit PedidoAprovado` garantizó la transparencia, anunciando a la red que la regla de gobernanza se cumplió. Este mecanismo de aprobación múltiple se fundamenta en los principios de consenso y seguridad descentralizada propuestos por Nakamoto (2008), donde la validez de una operación depende de la concordancia de una mayoría, protegiendo el sistema contra decisiones arbitrarias. La utilización del consenso permite la creación de sistemas “trustless”, donde la confianza reside en la verificación objetiva de las reglas del código (Kuiper & Hogan, 2023).

Se analizó la eficiencia computacional del mecanismo de quorum, evidenciando una reducción significativa en el consumo de recursos entre la primera y la segunda aprobación de una misma solicitud. La lógica de gobernanza implementada se benefició de la optimización de estados de la Ethereum Virtual Machine, con una reducción de aproximadamente el 31% en el costo de ejecución. Esta reducción provino de la manipulación de variables de estado ya iniciadas (hot slots), un incentivo técnico para la eficiencia del ledger, donde la escritura inicial de datos (SSTORE) es intencionalmente más onerosa para garantizar la sostenibilidad de la red (Antonopoulos; Wood, 2018). Esta métrica valida la escalabilidad del prototipo, demostrando que los sistemas de firmas múltiples pueden operar con previsibilidad de costos (Badev & Chen, 2014).

El mecanismo de transparencia y auditoría del prototipo fue demostrado mediante el acceso directo a los registros internos del contrato a través de la función `getPedido`. Esta función, definida con el modificador `view`, permitió la consulta pública, inmutable y gratuita de los datos almacenados en el ledger, incluyendo la dirección de destino, el valor, la descripción, el número de aprobaciones y el estado de ejecución. La persistencia de la información ocurrió de forma estructurada, permitiendo la verificación del estado actual de cualquier solicitud, incluido el quórum de aprobación acumulado. El comando `require` funcionó como una verificación de integridad, y la utilización del término `storage` señaló que los datos fueron buscados directamente en la memoria permanente de la blockchain, garantizando la fidelidad del historial registrado.

La funcionalidad de consulta se basa en la naturaleza pública y cronológica de la blockchain, descrita por Nakamoto (2008) como un libro mayor distribuido donde cada transacción se documenta de forma auditable por todos los participantes. La disponibilidad pública de estos registros es el elemento central que permite a cualquier agente verificar la consistencia de las operaciones sin recurrir a una autoridad central o intermediaria (Badev & Chen, 2014). Al permitir que los donantes y auditores ejecutaran la función de lectura de forma gratuita e inmutable “on-chain”, la solución materializó los conceptos de visibilidad total e integridad digital, esenciales para la prevención de fraudes en flujos de donaciones.

La etapa de liquidación financiera y actualización del estado del contrato fue detallada por la ejecución de la función `executarPedido`, realizada exclusivamente después de la validación del quórum mínimo de firmas autorizadas. La transacción se procesó con éxito, conforme a las reglas de gobernanza programadas. La actualización en tiempo real del saldo financiero del smart contract, con la reducción del saldo en Ethereum, constituyó la prueba empírica de la salida de recursos a la dirección de destino después de la llamada a la función de transferencia en el código. Esta ejecución automatizada y condicionada refleja los fundamentos descritos por Antonopoulos y Wood (2018), donde los smart contracts actúan como agentes autónomos que garantizan el cumplimiento de reglas de negocio complejas sin intervención manual o intermediarios financieros.

Al integrar la lógica de quórum directamente en la Ethereum Virtual Machine, el prototipo aseguró la integridad del proceso de toma de decisiones, materializando el modelo de seguridad descentralizada propuesto por Nakamoto (2008), donde la validez de una operación depende de la verificación objetiva del protocolo. La inmutabilidad y la transparencia generadas por esta transacción fundamentan la “revolución de la confianza” (Tapscott & Tapscott, 2016), permitiendo que cada etapa del flujo de donaciones sea públicamente auditable y inmune a alteraciones retroactivas. La visibilidad total del ledger posibilita la trazabilidad en tiempo real, resolviendo el problema de opacidad en flujos financieros (Laurence, 2019). La consolidación de este registro en la blockchain transforma la auditoría en un proceso nativo de la plataforma.

La implementación de la función `executarPedido` en lenguaje Solidity consolidó el cierre del flujo de gobernanza, permitiendo la transferencia efectiva de los recursos solo después de la validación rigurosa de todas las premisas de seguridad establecidas en el protocolo. El análisis de la función indicó que la ejecución automatizada y condicionada reflejó los fundamentos de autonomía discutidos por Antonopoulos y Wood (2018). El comando `require(!p.executado)` funcionó como un bloqueo de seguridad, impidiendo errores operacionales o intentos de duplicidad de pago. La línea `p.aprovacoes >= quorumMinimo` materializó el modelo de seguridad descentralizada propuesto por Nakamoto (2008), asegurando que la validez de la operación dependiera de la verificación objetiva del protocolo y no de la arbitrariedad de un administrador único.

La transferencia realizada mediante el comando `call` resultó en la actualización inmediata del saldo del contrato en la red de pruebas, proporcionando la prueba empírica de la salida de recursos. La emisión del evento final `PedidoEjecutado` consolidó la transparencia del sistema, permitiendo que donantes y auditores rastreen la liquidación en tiempo real, resolviendo el problema de opacidad financiera identificado en esta investigación. Aunque el prototipo utiliza el escenario de una ONG ficticia, la estructura técnica de multisig y gobernanza es plenamente adaptable para el uso por individuos o colectivos, asegurando que cualquier historial de movimiento financiero sea transparente para todas las partes involucradas.

Las métricas de consumo de recursos computacionales observadas durante las pruebas operacionales del prototipo se detallaron, expresadas en unidades de “gas”. La implementación del contrato (“Constructor”) presentó el mayor costo de transacción, con 1.582.730 gas, y de ejecución, con 1.406.910 gas, resultando en un costo estimado de 0,00158273 ETH ficticio. La función `crearPedido` consumió 123.507 gas de transacción y 101.407 gas de ejecución, con un costo estimado de 0,00012351 ETH ficticio. Para la primera aprobación de pedido, el costo de transacción fue de 75.734 gas y de ejecución 54.542 gas, totalizando 0,00007573 ETH ficticio. La segunda aprobación de pedido demostró mayor eficiencia, con 58.634 gas de transacción y 37.442 gas de ejecución, resultando en 0,00005863 ETH ficticio.

La ejecución de la orden (`executarPedido`) tuvo un costo de transacción de 66.411 gas y de ejecución de 45.219 gas, con un costo estimado de 0,00006641 ETH ficticio. Las funciones de consulta, como `getPedido`, `ehAprovador` y `totalPedidos`, no consumieron tarifas cuando se ejecutaron de forma externa y gratuita en la red, presentando costos de ejecución de 15.047, 2.899 y 2.506 gas, respectivamente, siendo exentas de costo en ETH ficticio. Esta distinción entre funciones de escritura y consulta fundamenta la transparencia del sistema, permitiendo auditoría pública sin costos de transacción para el observador externo (Badev & Chen, 2014).

La implementación del contrato es la operación más onerosa, justificada por el almacenamiento de la lógica y las reglas de gobernanza directamente en la red. Según Antonopoulos y Wood (2018), el costo de gas es un mecanismo de protección de la red contra bucles infinitos y uso ineficiente de la Ethereum Virtual Machine, donde las operaciones de escritura (SSTORE) tienen tarifas elevadas para garantizar la sostenibilidad del ledger descentralizado. La segunda aprobación de una solicitud resultó en un costo inferior (58.634 gas) comparado con la primera (73.734 gas), evidenciando la eficiencia de la EVM al lidiar con variables de estado ya iniciadas (slots de memoria “calientes”), lo que favorece la escalabilidad de la gobernanza colectiva en el prototipo. La asignación de un valor físico a cada acción del contrato materializa el concepto de “checks and balances” (Fidelity Digital Assets, 2023; Kuiper & Hogan, 2023), desincentivando el uso malicioso y garantizando que solo transacciones legítimamente aprobadas por el quórum sean procesadas.

La arquitectura lógica del prototipo se fundamentó en cuatro pilares operativos: custodia y control de saldo vía contrato, creación de solicitudes de transacción con metadatos esenciales, registro descentralizado de aprobaciones por direcciones autorizadas y ejecución final condicionada al logro de un quórum mínimo. Esta configuración materializa la lógica de un contrato de firma múltiple (multisig), indicando que la gobernanza del sistema no reside en una autoridad central, sino en la verificación programática de reglas de consenso preestablecidas en el código. Este diseño estructural se alinea con los conceptos de Szabo (1997) y Nakamoto (2008), quienes propusieron la ejecución autónoma de reglas contractuales y sistemas de pago basados en prueba criptográfica, respectivamente. La separación entre la creación de la solicitud y su ejecución funciona como un mecanismo de “checks and balances”, esencial para la integridad en sistemas descentralizados (Fidelity Digital Assets, 2023).

Las evidencias preliminares y validaciones realizadas registraron el éxito en la compilación del código en el entorno Remix IDE, la validación de la estructura lógica de las funciones y la realización de pruebas funcionales básicas, incluyendo la lectura de variables de estado y el retorno de llamadas que no demandan consumo de saldo (“gasless calls”). Estos procedimientos iniciales aseguraron que la sintaxis y la lógica interna del contrato están en conformidad con los estándares del lenguaje Solidity en la versión 0.8.20. La validación de estas funciones de lectura y escritura es fundamental para confirmar la prontitud del contrato para ser procesado por la Ethereum Virtual Machine (EVM). Conforme señalado por Buterin (2013), la transición del código estático a un contrato inteligente funcional transforma el software en un repositorio lógico inmutable y auditable dentro de la red. La estabilidad demostrada en las pruebas de lectura de variables refuerza la confiabilidad de la persistencia de datos “on-chain”, elemento central para la garantía de la integridad temporal de los registros de donación (Haber & Stornetta, 1991).

El enfrentamiento analítico entre las funcionalidades del prototipo y el marco teórico demostró la validación de los conceptos fundamentales. El prototipo implementó sistemas “trustless” mediante la ejecución vía código sin necesidad de administrador central, alineándose a Kuiper y Hogan (2023). La inmutabilidad fue garantizada por registros permanentes e irreversibles en la red Sepolia, conforme Nakamoto (2008). La transparencia digital fue materializada por la auditoría pública y gratuita vía la función `getPedido`, corroborando Badev y Chen (2014). La automatización contractual fue evidenciada por el disparo automático de transferencia tras alcanzar el quórum, siguiendo a Szabo (1997). Finalmente, la eficiencia de estado fue comprobada por la reducción de costo de gas en variables ya inicializadas, conforme Buterin (2013).

La correlación presentada indica que el prototipo no solo ejecuta comandos computacionales, sino que materializa las reglas de gobernanza propuestas por Szabo (1997) y Nakamoto (2008). La capacidad de auditar el quórum de aprobación de forma “on-chain” reduce la asimetría de información, resolviendo el problema de opacidad en flujos financieros identificado en la introducción de este trabajo. Esta validación técnica, incluso ocurriendo en un entorno de prueba, confirma la viabilidad de sistemas descentralizados para la gestión de donaciones, alineándose a la “revolución de la confianza” prevista por Tapscott y Tapscott (2016).

Entre las limitaciones y desafíos observados, destaca la dependencia de infraestructura externa, especialmente la estabilidad de redes de prueba y la obtención de saldo ficticio vía “faucets” para la ejecución de transacciones con movimiento de valor. Esta dependencia indica que el desarrollo de soluciones distribuidas exige una planificación adicional rigurosa, ya que la latencia de la red y la disponibilidad de recursos en entornos como Sepolia o Ganache impactan la cadencia de las evaluaciones funcionales. La gestión de tarifas de red (gas) y la integración con infraestructuras de terceros son aspectos técnicos inherentes a los smart contracts en plataformas públicas, imponiendo desafíos de escalabilidad y costo que deben ser mitigados en la fase de prototipado (Antonopoulos; Wood, 2018).

Las pruebas realizadas confirmaron la naturaleza seudónima de la blockchain, demostrando que el rastreo obtenido se limita al flujo digital de direcciones “on-chain”. En la práctica, se observa la imposibilidad de determinar la identidad civil real detrás de cada dirección solo con los metadatos proporcionados por la red. Esta limitación es una característica fundamental del modelo de privacidad propuesto por Nakamoto (2008), donde las transacciones se anuncian públicamente, pero la identidad de los propietarios de las claves permanece disociada del registro. Aunque el ledger es transparente y auditable por cualquier participante, la frontera entre la visibilidad técnica y la identificación del mundo real permanece como un desafío para la aplicación de la tecnología en contextos que exijan estricto cumplimiento legal (KYC – “Know Your Customer”), según análisis de Badev y Chen (2014).

La viabilidad práctica del modelo de trazabilidad propuesto reside en la simplicidad de su arquitectura de código abierto, lo que garantiza un alto índice de reproducibilidad y replicación por diferentes organizaciones del tercer sector. Para que otra institución filantrópica adopte el sistema, el procedimiento operativo se limita a la parametrización del método constructor en el momento de la implantación del contrato inteligente en la red. En esta etapa, la organización debe definir las direcciones criptográficas de sus gestores autorizados y establecer el quórum de firmas coherente con sus reglas de gobernanza interna. Esta característica técnica atiende a los conceptos de desintermediación y autonomía sistémica discutidos por Tapscott y Tapscott (2016), ya que permite que cada entidad configure un entorno personalizado de pesos y contrapesos digitales sin necesidad de desarrollar una nueva solución de software desde cero.

La transición del prototipo preliminar a un entorno de producción real exige adaptaciones estructurales importantes. En instituciones de gran tamaño, el modelo estático de aprobadores definido en el constructor del contrato puede volverse obsoleto ante la rotación de personal y los cambios en la dirección. Para mitigar esta limitación, la arquitectura de software debe adaptarse para incluir funciones dinámicas de gestión de permisos, permitiendo la inserción o exclusión de direcciones aprobadoras mediante aprobación colectiva previa por quórum. Además, la dependencia de interfaces técnicas complejas como Remix IDE restringe el uso del sistema a usuarios especializados. La replicación a escala real demanda el desarrollo de una capa de interfaz con el usuario (“front-end”) amigable, capaz de traducir las llamadas a funciones Solidity en botones visuales simples e integrar la billetera digital MetaMask de forma intuitiva, reduciendo la barrera de entrada para gestores no técnicos.

Desde la perspectiva de la escalabilidad y la sostenibilidad financiera, las limitaciones impuestas por la fluctuación de las tasas de red (gas) en la capa principal de Ethereum exigen decisiones arquitectónicas estratégicas. Según lo analizado por Badev y Chen (2014), la planificación de costos es determinante para la adopción tecnológica en organizaciones sin fines de lucro. En escenarios de alto volumen de transacciones o donaciones recurrentes de pequeño valor, el procesamiento directo en la red principal se vuelve inviable. Para sortear este cuello de botella, la infraestructura técnica debe implementarse en redes de segunda capa (Layer 2), las cuales agregan y procesan las transacciones fuera de la cadena principal, reduciendo significativamente las tarifas computacionales mientras heredan la seguridad criptográfica de la red descentralizada subyacente, según lo propuesto por Buterin (2013).

La aplicabilidad en contextos reales de gobernanza y auditoría regulatoria impone la necesidad de integrar la transparencia técnica de la blockchain con los marcos civiles y jurídicos del mundo físico. Aunque la inmutabilidad del registro asegura la integridad cronológica de las acciones de las direcciones involucradas (Nakamoto, 2008), el seudónimo de las billeteras digitales impide la validación inmediata de la identidad real de los gestores ante órganos fiscalizadores externos. Por lo tanto, adaptaciones futuras deben considerar la integración con protocolos de identidad descentralizada (Identificadores Descentralizados – DID) y procesos de verificación de identidad (Conozca a su Cliente – KYC) fuera de la red (“off-chain”). Esta convergencia entre la soberanía algorítmica del software y las exigencias legales de cumplimiento civil constituye el nexo necesario para consolidar la confianza mutua y la transparencia integral en las donaciones filantrópicas.

En resumen, el prototipo demostró la eficacia de la tecnología blockchain y los contratos inteligentes en la promoción de la transparencia e integridad de los registros digitales para donaciones. Se confirmó la validación del control de acceso basado en roles y la conformidad lógica del quórum de aprobación, y se evidenció la previsibilidad de los costos computacionales, junto con la eficiencia de la Ethereum Virtual Machine. La emisión de eventos on-chain permitió la reconstrucción integral del flujo decisorio, garantizando la auditabilidad permanente del sistema y materializando la desintermediación financiera a través de pruebas criptográficas, lo que proporciona una herramienta eficaz para la gobernanza descentralizada y la visibilidad total de los recursos, respondiendo al objetivo de desarrollar y validar un prototipo funcional de trazabilidad.

4. Conclusión

El estudio buscó desarrollar y validar un prototipo funcional de trazabilidad para el flujo de donaciones digitales utilizando la tecnología blockchain y contratos inteligentes. Se verificó la viabilidad técnica de la solución, confirmando el control de acceso basado en funciones y la conformidad lógica del quórum de aprobación. El análisis de las métricas de rendimiento indicó la previsibilidad de los costos computacionales y la eficiencia de la Ethereum Virtual Machine en el procesamiento de reglas de gobernanza inmutables. Se observó que la emisión de eventos on-chain permitió la reconstrucción integral del flujo decisorio, garantizando la auditabilidad permanente del sistema. La principal contribución reside en la materialización de la desintermediación financiera a través de pruebas criptográficas, proporcionando una herramienta eficaz para la gobernanza descentralizada y la visibilidad total de los recursos, lo que resuelve el problema de opacidad en flujos financieros.

Sin embargo, se identificó que la dependencia de infraestructuras externas, como la estabilidad de las redes de prueba y la obtención de saldo ficticio, representa una limitación operativa. La volatilidad de las tasas de red y el desafío de la custodia individual de claves privadas también se observaron, transfiriendo la responsabilidad de seguridad a los gestores. Adicionalmente, la naturaleza seudónima de la blockchain impide la vinculación directa de direcciones a identidades civiles, lo que impone desafíos para el cumplimiento legal estricto. Para estudios futuros y la aplicabilidad a gran escala, se sugiere la transición a redes de segunda capa o cadenas laterales para optimizar costos y escalabilidad. Se recomienda también el desarrollo de interfaces de usuario más amigables y la integración con protocolos de identidad descentralizada y procesos KYC off-chain, con el objetivo de la convergencia entre la soberanía algorítmica y las exigencias regulatorias del mundo físico.

Referencias Bibliográficas

“””

# Fallback para formatos de cita malformados o inesperados, aunque la entrada parece consistente.

# Para autores individuais, pegue a última palavra (suposto sobrenome)

# Manejo específico para autores corporativos conhecidos

# Dividir por separadores comunes: ‘;’, ‘ e ‘, ‘ & ‘

“`python

author_names = re.split(r’;| y | & ‘, author_part)

parte_autor = partes[0].quitar_espacios()

def parse_citation(citation_string):

si no:

para nome em autor_nomes:

Maneja varios separadores de autor (;, e, &) y autores corporativos.

si “Fidelity Digital Assets” en author_part:

si len(parts) != 2:

if name: # Asegurarse de que name no esté vacío

import re

autores_clave = set()

key_authors.add(“fidelity digital assets”)

key_authors.add(name.split()[-1].lower())

nombre = nombre.recortar()

Analiza una cadena de cita para extraer autores clave (apellidos o nombre corporativo completo) y año.

partes = citation_string.rsplit(‘,’, 1)

devolver {‘autores_clave’: autores_clave, ‘año

return {‘key_authors’: {citation_string.lower()}, ‘year’: 0, ‘original_string’: citation_string}

año = int(año_str)

cadena_año = partes[1].recortar()

Artículo originado del Trabajo de Conclusión de Curso de la Especialización en Ingeniería de Software del MBA USP/Esalq

Para saber más sobre el curso, haz clic aquí y accede a la plataforma MBX Academy