¿Sería esta una implementación válida para un grupo de participación de ether si el objetivo fuera eliminar la necesidad de que los depositantes pierdan el control de su ether al propietario del grupo?
El depositante crea un contrato y envía el éter que desea apostar a ese contrato
El contrato controla 2 de 3 claves en una dirección multisig y el propietario del grupo controla la otra clave
El propietario del grupo llama a una función en el contrato, proporcionando información sobre el bloque que desea votar
Luego, el contrato generaría una firma para el bloque utilizando una de las dos claves de los depositantes y devolvería la firma al propietario del grupo.
El propietario del grupo también crearía una firma usando la clave que controlan.
Juntas, las firmas del depositante y del propietario del grupo constituyen una prueba de propiedad del éter apostado y, por lo tanto, un voto para cualquier bloque sobre el que el propietario del grupo proporcionó información.
El propietario del grupo podría enviar un voto y repetir el proceso nuevamente.
El contrato tendría un límite de gasto de 0 éter a menos que las claves utilizadas para firmar un tx incluyeran las dos claves de los depositantes (evitar que el operador del grupo robe fondos)
Estaba leyendo sobre la necesidad de velocidad en la actualización de los votos en bloque para reducir la pérdida de fondos debido a DDoS aquí , y estaba tratando de pensar en posibles implementaciones que evitarían que el depositante introduzca demoras adicionales en el proceso de votación.
Si el grupo necesitara solicitar una firma de un depositante, y el depositante tenía su éter apostado usando un cliente 'EthPool-Qt' que se ejecutaba localmente y generaba firmas para el grupo, ¿no aumentaría significativamente el retraso introducido por la red el potencial no ¿cambiar los votos lo suficientemente rápido, quedar en el lado perdedor y, por lo tanto, perder el éter en juego?
¿Crees que los pools que requieren que los depositantes pierdan el control de su ether tendrán una ventaja al apostar porque simplemente pueden votar en bloques porque literalmente serían dueños de todo el ether de los depositantes y podrían crear votos sin necesidad de recolectar firmas adicionales?
El enfoque de participación agrupada más simple sería hacer que el código de validación de una cuenta sea un verificador de múltiples firmas en lugar de un verificador de una sola firma, es decir. esperaría firmas de M de un conjunto dado de N claves públicas (puede hacer que esto sea más eficiente usando umbrales de firmas en lugar de multifirmas).