En Ethereum PoW la recomendación es esperar 12 confirmaciones como mínimo.
[P] : ¿Qué reglas aplicar para el algoritmo Geth PoA Clique?
Mi mejor conjetura hasta ahora:
límite inferior : suma de las dificultades del bloque de confirmación >= (piso(N/2) + 1) * 2
límite superior : suma de las dificultades del bloque de confirmación <= N * 2
donde N = número de selladores en la red
La razón por la que estoy multiplicando con 2 es que los selladores en orden están contribuyendo con 2 a la dificultad del bloque, de lo contrario, es 1.
Actualizar _ Después de leer el artículo de Castro/Liskov sobre PBFT ( http://pmg.csail.mit.edu/papers/osdi99.pdf ), creo que la regla de 2*f + 1confirmaciones para a N = 3*f + 1también se aplica a Clique. Al menos como límite inferior. El límite superior podría permanecer como está. Vea el comentario a continuación.
Como nadie ha proporcionado una respuesta hasta ahora, intentaré resumir mi investigación sobre esto. Si alguien puede proporcionar una mejor "historia", cambiaré la marca de verificación.
Después de leer el artículo sobre pBFT de Castor/Liskov , creo que la regla del 66,6 % + 1 de pBFT también se aplica a Clique. Por lo tanto, 50% + 1 no es suficiente para estar seguro de que la transacción no se puede eliminar de la cadena después de una reorganización.
Hasta ahora solo tengo un ejemplo como prueba: en un sistema con 5 selladores (N = 5), podría tener un sellador deshonesto S3 capaz de dividir la red en {S1,S2,S3} y {S3,S4,S5 } (por ejemplo, por un ataque DDoS), por lo que {S2,S3} no puede comunicarse con {S4,S5}. Ambas redes seguirán ejecutando su propia bifurcación mientras S3 participe (50 %+1). Cuando esté en su turno, podría proponer un bloque válido con una transacción TX y publicarlo solo en {S4, S5}, mientras que, por otro lado, crear un bloque alternativo con una transacción de doble gasto TX 'publicar solo en {S1, S2 }. Después de 50%+1 de confirmaciones en {S3,S4,S5}, podría dejar de publicar bloques en esta subred y dejar que {S1,S2,S3} sea más pesado. Después de eso, puede liberar el bloqueo en la comunicación, y el protocolo GHOST resolvería la bifurcación seleccionando la cadena más pesada,
En este sentido, el número mínimo de confirmaciones tendrá que ser: 66,6% + 1 [más precisamente: N - floor((N-1)/3)] diferentes selladores han confirmado la transacción, lo que es análogo a pBFT.
Acerca del "límite superior" como se define anteriormente en la pregunta (suma de las dificultades del bloque de confirmación <= N * 2). En realidad, esto no tiene sentido, ya que S3 podría dejar que ambas bifurcaciones funcionaran lo suficiente como para satisfacer esta condición y, más tarde, podría darle una ventaja a la rama deseada al detener la comunicación en la otra rama.
ismael
ivicaa