# 🗳️ Trabajo Final Módulo 2 ## 📜 Solidity Smart Contracts > **🗓️ Fecha de entrega:** 23 de Octubre hasta las 23:59 > **🛠️ Plataforma de Desarrollo:** Remix IDE > **✍️ Lenguaje:** Solidity ^0.8.20 --- ## 🎯 Consigna ### 1. Objetivo Principal Diseñar y desarrollar un contrato inteligente en Solidity que sirva como la base para una aplicación de votación electoral descentralizada. El sistema debe ser seguro, transparente y gestionar un proceso electoral de principio a fin. **Se valora la creatividad en el diseño y la implementación, siempre que se cumplan los conceptos clave.** ### 2. Contexto del Problema Imagina que tienes la tarea de construir un sistema de votación para una organización, comunidad o incluso un pequeño país, que desconfía de las soluciones centralizadas. Tu objetivo es usar la tecnología blockchain para crear un sistema donde las reglas son claras, el proceso es auditable y los resultados son indiscutibles. ### 3. Conceptos y Requisitos Clave Tu contrato debe gestionar un ciclo electoral lógico. Piensa en cómo debería funcionar una elección real y traslada esa lógica al contrato. * **👑 El Administrador Electoral (`admin`):** Debe existir un rol de administrador, que será la cuenta que despliega el contrato. Esta figura es responsable de configurar y controlar el flujo de la elección. * **🚦 Fases del Ciclo Electoral:** El contrato debe tener un ciclo de vida claro. Como mínimo, debe manejar los siguientes estados o fases: 1. **Preparación/Registro:** Una fase inicial donde el `admin` prepara todo. Aquí se deberían poder añadir los candidatos y definir quiénes están habilitados para votar. 2. **Período de Votación:** Una fase activa donde los votantes autorizados emiten su sufragio. Durante este tiempo, la configuración de la elección (candidatos, votantes) debería estar bloqueada. 3. **Elección Finalizada:** Una vez cerrada la votación, el sistema debe entrar en un estado final donde se pueden consultar los resultados de forma definitiva. * **🗳️ Lógica de Votación:** * Solo las direcciones autorizadas por el `admin` pueden votar. * Cada votante autorizado tiene derecho a **un solo voto**. * Debe ser imposible votar por un candidato que no existe. * **📊 Transparencia:** * Cualquier persona debe poder ver la lista de candidatos. * Una vez finalizada la elección, cualquiera debe poder consultar quién fue el ganador. ### 4. Pistas y Sugerencias Técnicas (¡No son obligatorias!) Aquí tienes algunas ideas sobre cómo podrías abordar el problema. Siéntete libre de usar estas herramientas o proponer las tuyas. * **Estados de la Elección:** ¿Cuál es la mejor forma de representar las fases (`Registro`, `Votación`, `Finalizada`) para evitar errores? Un `enum` podría ser una excelente opción. * **Agrupación de Datos:** Un candidato tiene un nombre y un contador de votos. Un votante tiene un estado (¿autorizado?, ¿ya votó?). ¿Qué herramienta de Solidity te permite agrupar datos relacionados? Los `structs` son muy útiles para esto. * **Control de Acceso:** ¿Cómo te aseguras de que solo el `admin` pueda realizar acciones críticas como añadir candidatos o iniciar la votación? Investigar y crear tus propios `modifiers` es una práctica fundamental en Solidity. * **Notificaciones:** ¿Cómo puede una aplicación externa (un front-end) enterarse de que se ha emitido un voto o que la elección ha finalizado sin tener que consultar el contrato constantemente? El uso de `events` es la solución idiomática. ### 5. Consideraciones de Seguridad Independientemente de tu diseño, asegúrate de que tu contrato sea seguro. Piensa en: * ¿Qué pasa si alguien intenta votar dos veces? * ¿Puede alguien que no es el `admin` finalizar la elección? --- ## Evaluación ### ✅ Entregables 1. El código fuente completo en un archivo `.sol` y desplegado en la red de sepolia. 2. Un archivo `README.md` o documentar cada linea de codigo que explique tu diseño, las decisiones que tomaste y cómo probar tu contrato. 3. El contrato debe estar verificado 4. **(Opcional)** Pruebas unitarias que demuestren que tu contrato funciona como se espera. --- ## 💯 Criterios de Evaluación * **Lógica de Negocio (40%):** ¿El contrato resuelve el problema planteado de forma coherente y completa? * **Seguridad y Robustez (30%):** ¿El contrato es seguro y maneja correctamente los casos de borde? * **Calidad y Creatividad del Código (20%):** ¿El código es legible, bien estructurado y demuestra un buen entendimiento de los patrones de diseño de Solidity? * **Documentación y verificación (10%):** ¿El `README.md` o comentarios en el contrato explica claramente tu solución? --- ## 🚀 Desafío Extra (Bonus) Si quieres ir un paso más allá, considera añadir una de estas funcionalidades avanzadas: * **Delegación de Voto:** Permite que un votante ceda su derecho a voto a otra dirección de confianza.