Durante este tiempo, se ha realizado una prueba completa de almacenamiento para una DApp de conciliación de privacidad en el ecosistema de Midnight, centrándose principalmente en la estabilidad del estado privado local de Leveldb, la velocidad de expansión y la fiabilidad de la recuperación de copias de seguridad. Se ejecutó durante 20 días consecutivos, y el directorio del estado privado pasó de 1.2GB a 4.8GB, al mismo tiempo que se descubrió que el mecanismo de copia de seguridad proporcionado oficialmente tiene varios aspectos que se pueden mejorar, lo que realmente afecta la seguridad y el cumplimiento de los datos en escenarios de nivel institucional. Este artículo, junto con los datos de la prueba, organiza las raíces de los problemas, el alcance del impacto y las recomendaciones operativas que se pueden implementar directamente, para la referencia de los desarrolladores y el personal de operaciones de Midnight.
La DApp que se está probando está diseñada principalmente para que instituciones pequeñas y medianas realicen conciliaciones de privacidad en la cadena, la actividad diaria no es la más alta, pero la frecuencia de transacciones no es baja, desarrollada sobre el protocolo Kachina de Midnight, todos los estados privados se almacenan en Leveldb local. Esta prueba real es para ver si este almacenamiento puede soportar la carga en un negocio real, y para identificar problemas operativos anticipadamente, proporcionando una base para futuras optimizaciones.
Los datos son muy claros: después de 20 días, la carpeta de estado privado pasó de 1.2GB a 4.8GB, la velocidad de crecimiento es bastante rápida. Después de investigar, las razones principales son dos:
Primero, el protocolo Kachina aún no ha implementado la limpieza automática de caché de testigos, datos intermedios de prueba histórica y registros de retroceso, acumulándose cada vez más archivos temporales;
El problema es que el propio Leveldb tiene un aumento de escritura evidente, las actualizaciones son escrituras adicionales, los datos antiguos deben esperar la Compaction para ser realmente eliminados, lo que aumenta aún más la ocupación del disco.
Además, Midnight, por motivos de seguridad de privacidad, ha realizado la serialización y encriptación de cada valor en Leveldb, aumentando la seguridad, pero también aumentando el espacio de almacenamiento. Después de las pruebas, la ocupación del disco después de la encriptación es más de 3 veces superior a la de los datos originales. La cantidad de estado original generada por las instituciones en su conciliación diaria es aproximadamente 50MB, después de procesarse en Leveldb llega a 200MB, y tras la encriptación directamente a 300MB, por lo que es necesario planificar la capacidad a largo plazo.
La recuperación de copias de seguridad fue un enfoque clave en esta prueba.
El documento de Midnight v1.3.0 deja claro que el estado privado se encuentra localmente, lo que puede evitar filtraciones de datos. Sin embargo, después de las pruebas, el script de respaldo oficial aún tiene un espacio evidente para mejorar: el script solo respalda los archivos de estado encriptados, no incluye el índice de claves necesario para la desencriptación, lo que resulta en un error de "no se puede verificar la integridad del estado" y no se puede recuperar.
También intenté con copias de seguridad en la nube usando AWS S3 y descubrí que es un típico dilema de equilibrio de seguridad: si la clave se deja localmente, los archivos encriptados en la nube no pueden abrirse, y la copia de seguridad sería inútil; si la clave se envía a la nube, se contradice el principio de diseño de seguridad de "estado privado no salir de local". Los desarrolladores deben encontrar un punto de equilibrio entre la seguridad y la disponibilidad de respaldo.
Aquí aclaremos un punto: los problemas que surgieron en esta prueba se deben ver en dos categorías.
Una categoría son los puntos de optimización en la implementación del proyecto, como la falta de índices de claves en los scripts de respaldo y la falta de limpieza automática, que pueden ser compensados en las próximas iteraciones del software;
La otra categoría son las concesiones a nivel de diseño, como el uso de Leveldb local por motivos de privacidad, lo que trae costos adicionales, que es un equilibrio normal entre privacidad y rendimiento. La lógica de privacidad del protocolo Kachina es sólida, pero hay margen para mejorar en la implementación y la facilidad de uso operativo.
Una comparación horizontal con otras cadenas de privacidad también muestra la brecha:
Leo utiliza un modelo de registro, que admite la depuración de registros históricos, manteniendo solo los datos efectivos esenciales;
Filecoin FVM se integra nativamente con IPFS, lo que permite enviar grandes volúmenes de estado a almacenamiento distribuido, aliviando la presión local.
Actualmente, Midnight aún no tiene fragmentación de almacenamiento, archivo de datos ni separación de datos fríos y calientes; todos los datos están mezclados, lo que aumenta la presión operativa con el tiempo.
También se probaron muchos problemas en la sincronización del estado.
La sincronización de pruebas de prueba de Merkle con nuevos dispositivos es promedio; bajo la lógica de concurrencia de Kachina, sincronizar múltiples contratos a la vez puede desencadenar competencia por bloqueos en Leveldb. En las pruebas, sincronizar 80 estados de contrato tomó 42 minutos, con una ocupación de CPU de menos del 10%, el cuello de botella está casi todo en la espera de IO. Además, la sincronización no admite la reanudación desde un punto de interrupción; si se corta la red, hay que reiniciar; el formato sst de Leveldb es binario y puede estar bloqueado por procesos, por lo que usar rsync para sincronización incremental puede ser propenso a inconsistencias, y todo esto debe evitarse mediante estrategias operativas.
Para una DApp de tamaño mediano (800+ usuarios activos diarios, un promedio de 12 conciliaciones diarias por persona), se estima que en un año el consumo de almacenamiento podría llegar a 450GB, lo cual es más exigente en disco que una base de datos tradicional. Ya sea cambiando el disco local o ampliando el servidor en la nube, el costo es significativo. Además, con un volumen de datos más grande, la Compaction de Leveldb puede provocar pausas en la escritura, y durante los picos, la latencia de escritura del estado puede dispararse de 12ms a 2.3s, lo que afecta notablemente la fluidez del negocio.
Resumen de problemas centrales (problema-fenómeno-impacto-sugerencia)
1. La ocupación de almacenamiento de Leveldb aumenta rápidamente
En 20 días, de 1.2GB a 4.8GB, el volumen se amplió más de 3 veces tras la encriptación
→ Aumenta los costos de almacenamiento, incrementa la presión sobre los nodos
→ Sugerencia: configurar Compaction periódicamente, limpiar manualmente la caché de testigos y los archivos basura de pruebas históricas
2. El script de respaldo oficial no está completo
Solo se respalda el estado encriptado, no se respalda el índice de claves, la recuperación falla
→ Fallas en el disco duro pueden resultar en la pérdida de datos críticos de conciliación, afectando la conformidad
→ Sugerencia: scripts personalizados para sincronizar copias de seguridad de archivos de estado + índices de claves, mantener claves en respaldo frío offline
3. La eficiencia de sincronización del estado es relativamente baja
80 contratos sincronizados en 42 minutos, sin reanudación desde un punto de interrupción, competencia por bloqueos evidente
→ La incorporación de nuevos nodos es lenta, la eficiencia operativa es baja
→ Sugerencia: ajustar el orden de sincronización para evitar conflictos de bloqueos, dividir manualmente los sst y sincronizarlos por lotes
4. Datos fríos y calientes no separados
Los datos históricos y los datos activos se mezclan, la Compaction provoca pausas en la escritura
→ El retraso se dispara en los picos, disminuyendo la experiencia
→ Sugerencia: archivar manualmente datos históricos en almacenamiento externo, seguir el plan oficial de separación de datos fríos y calientes
En general, el almacenamiento local de Midnight es más adecuado para usuarios individuales y escenarios ligeros. Para realmente soportar aplicaciones a nivel empresarial, la capa de almacenamiento aún necesita ser perfeccionada. La capacidad de privacidad de Kachina es un punto destacado, pero carece de funciones esenciales como archivado automático, respaldos incrementales y separación de datos fríos y calientes, lo que dificulta cumplir completamente con los estándares de estabilidad y conformidad.
Optimizaciones operativas prácticas (prioridad de alta a baja)
1. Detener pérdidas de manera urgente
Implementar scripts de respaldo personalizados, respaldando archivos de estado + índices de claves juntos, asegurando protección doble con almacenamiento local + frío offline.
2. Control de costos
Activar automáticamente la Compaction de Leveldb en horas de baja actividad, limpiar periódicamente cachés inválidas, controlando así la velocidad de crecimiento.
3. Optimización de la experiencia
Ajustar la estrategia de sincronización de contratos para evitar la competencia por bloqueos y mejorar la velocidad de sincronización.
4. Arquitectura a largo plazo
Seguir las iteraciones de las versiones oficiales, prestar atención a la integración de almacenamiento distribuido, fragmentación de datos y otras capacidades, adaptándose gradualmente a escenarios empresariales.
Esta prueba real ha explorado a fondo el rendimiento del almacenamiento basado en Leveldb de los DApp del ecosistema de Midnight, identificando cuatro problemas centrales: la expansión del almacenamiento, los defectos de respaldo, la baja eficiencia de sincronización y la falta de separación de datos fríos y calientes. También se ha validado tanto la ventaja del diseño de privacidad de Kachina como las debilidades en su implementación. Las sugerencias dadas en el texto se basan en datos de pruebas reales, pueden usarse directamente en producción, ayudando a los desarrolladores y operativos a evitar problemas de almacenamiento y controlar costos. Con el tiempo, al seguir las iteraciones de las versiones oficiales, Midnight podrá mejor respaldar aplicaciones de diferentes escalas y hacer que el ecosistema se mantenga más estable.
#night @MidnightNetwork $NIGHT
