¿Por qué necesitamos "stateMutability" en el ABI del contrato si ya tenemos "constante" y "pagadero"? [duplicar]

stateMutability: una cadena con uno de los siguientes valores: puro (especificado para no leer el estado de la cadena de bloques), vista (especificado para no modificar el estado de la cadena de bloques), no pagable y pagadero (igual que el pago anterior).

constante: verdadero si la función se especifica para nunca modificar el estado de la cadena de bloques; pagadero: verdadero si la función acepta ether, el valor predeterminado es falso.

Dentro del diseño original, algunos casos de uso no fueron posibles de expresar. Por ejemplo, una función pura no tiene un equivalente.

Respuestas (1)

constantha quedado en desuso en favor de purey view- ver aquí

purese utiliza para funciones en las que el estado ni siquiera se lee (p. ej., funciones de tipo SafeMath), mientras que viewse utiliza para funciones que no cambian de estado pero sí lo leen.

en términos de ABI, constantse retuvo por compatibilidad con versiones anteriores:

Observaciones:

JSON ABI tiene una nueva mutabilidad de estado de campo introducida con un valor de cadena como el anterior

JSON ABI se mantiene constante/de pago por compatibilidad con versiones anteriores durante un tiempo

Fuente: comentario de Axic del 15 de agosto de 2017 aquí

Supongo que el OP no está interesado en la diferencia entre puro/vista/constantes, etc. Está preguntando por qué abi contiene el stateMutabilitytérmino ya que la vista/constante ya está definida en la firma de la función.
La respuesta es clara. constanty payablese retuvo por compatibilidad con versiones anteriores. ¡Gracias!