---
# System prepended metadata

title: 'Trabajo Práctico: Sistema de Votación Electoral Descentralizado'

---

# 🗳️ 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.