¿Como funciona el proceso de votación?

El equipo de desarrollo de ChronoBank explica cómo reducir los costos de las acciones de encuesta y de la implementación de los contratos de votación.

ChronoMint, como parte de su funcionalidad, provee la habilidad de organizar encuestas - herramienta necesaria para el ecosistema de decisiones estratégicas centrales.

Votaciones diseñadas en una blockchain deben de cumplir los siguientes requisitos:

• Seguridad
• Fiabilidad
• Precio por manipulación de encuestas (creación, votación, cierre)

El primer paso hacia el subsistema de votación ideal fue diseñado por un par de contratos (los llamaremos managers) que absorberían todo el trabajo de las encuestas y su administración. Vale la pena mencionar que mantener datos en almacenamiento para todo tipo de managers usa un contrato especial StorageManager.

📌StorageManager puede permitir o negar acceso al área de almacenamiento.

De regreso a las votaciones, decimos que estos contratos compartirán espacio de almacenamiento común y tendrán acceso a las variables compartidas. Por el otro lado, esto permitirá separar el proceso de votación en diversos contratos funcionales (recibir detalles, votar, manejar los datos de la encuesta) y descompone códigos de tamaños masivos a contratos más pequeños, por el otro lado, este truco une a todos los contratos y comparte estados entre ellos. Se vuelve difícil hacer cambios de una manera correcta. Además de la anteriormente mencionada desventaja, esta implementación tiene precios exorbitantes para crear votos y supone almacenar mucha información estadística. Todo eso no era lo que esperábamos de nuestras votaciones- queremos que nuestros usuarios sean parte de un ecosistema con facilidad y plena participación en su vida.

What is meant by the term “gas”?

Precio del gas para algunas acciones que hemos tenido con implementaciones de votaciones anteriores:

• Crear una encuesta- 787111
• Votar- 411641
• Terminar encuesta- 482976
• Borrar encuesta- 95073

Como puedes ver, estos no son buenos números y hay mucho todavía por mejorar….

Así que hemos decidido usar otro enfoque para nuestra nueva manera de votar. Como previamente, dejamos un contrato (VotingsManager) para manejar, crear encuestas en el sistema y obtener información en general- permanecerá siendo el punto de entrada para cualquier usuario que decida usar votaciones.

Pero la siguiente será la parte más emocionantes: En lugar de almacenar encuestas como un conjunto de propiedades de alcance compartida crearemos un nuevo contrato para cada encuesta.

📌Este movimiento nos permitirá refactorizar mucha lógica en contratos separados, simplificar los contratos y dejar nuestras intenciones más claras.

La única cosa que nos confundía era que cada vez que creamos un nuevo contrato para empezar una encuesta eso requeriría más gas por contrato implementado que las implementaciones anteriores (por mucha lógica y código dentro de este nuevo contrato).

Nuestras decisiones sobre este tema fueron reubicar toda esta lógica a un contrato de instancia única (lo llamaremos backend) serán implementadas una vez, y también durante la creación de una encuesta al hacer un nuevo contrato proxy en lugar de un contrato de encuesta completamente funcional.

Los contratos proxy creados tendrán una dirección de contrato backend y redirigirán todas las

llamadas a esa instancia. Los contratos proxy podrán ser fácilmente implementados con la instrucción _delegatecall_assembly la cual ejecuta funciones delegadas dentro del contexto de un contrato llamador (i. e. proxy) y las operaciones escribir/leer asociarán su valor con el contexto. A pesar de todas estas ventajas no podíamos regresar valores múltiples de un _delegatecall_ sin código especifico y verboso adicional, así que era como si tuviéramos que implementar nuestra función de regreso-múltiple justo en un contrato proxy. Gracias a las actualizaciones de Byzantinum a las que les fueron agregadas instrucciones de ensamblaje muy prácticas y útiles _returndatasize_an_returndatacopy_. Estas instrucciones devuelven el tamaño de los datos devueltos de la función delegada y copian los datos devueltos en una memoria. Ahora podemos encontrarles un buen lugar para su aplicación- se utilizan en nuestro contrato proxyy, limpia su código de cualquier específicos de funciones backend. Después de eso tendremos un contrato que será creado siempre que una nueva encuesta vaya a ser creada y tomará una pequeña cantidad de gas para implementar un contrato casi vacío.

Precio de gas por la misa acción después de los cambios:

• Crear una encuesta- 849476
• Votar- 159331
• Terminar encuesta- 443473
• Eliminar encuesta- 56486

☞ Chart https://live.amcharts.com/I0ODU/

Como puedes ver obtuvimos casi una tercera parte menos de los gastos al realizar operaciones de  

votación que en una escala significante ahorrará muchos recursos para los usuarios.

Si, aún tenemos un aumento en la creación de encuestas, pero fue un precio aceptable para reducir las operaciones de votaciones. Otros métodos como cerrar y eliminar una encuesta también mostraron una reducción en el consumo de gas.

Implementando subsistemas de votación:

v.1: 3089834 + 3789833 + 2891094 = 9.770.761

v.2: 2440890 + 586243 + 3014376 = 6.041.509

____________________________________________________________________________

Artículo original en inglés:

https://blog.chronobank.io/how-does-voting-process-work-948ac7438376

TIME se está cotizando en las siguientes divisas: https://coinmarketcap.com/assets/chronobank/#markets

Website https://chronobank.io/

Twitter https://twitter.com/ChronobankNews

Facebook https://www.facebook.com/ChronoBank.io/

Telegram https://telegram.me/chronobank