Un ejemplo simple que demuestra este efecto se ve así:

pragma solidity^0.4.12;

contract Test {
    function test(uint[20] a) public returns (uint){
         return a[10]*2;
    }

    function test2(uint[20] a) external returns (uint){
         return a[10]*2;
    }
}

Al llamar a cada función, podemos ver que la publicfunción usa 496 gas, mientras que la externalfunción usa solo 261.

La diferencia se debe a que en las funciones públicas, Solidity copia inmediatamente los argumentos de la matriz en la memoria, mientras que las funciones externas pueden leer directamente desde los datos de llamada. La asignación de memoria es cara, mientras que la lectura de datos de llamadas es barata.

La razón por la que publiclas funciones necesitan escribir todos los argumentos en la memoria es que las funciones públicas pueden llamarse internamente, lo que en realidad es un proceso completamente diferente al de las llamadas externas. Las llamadas internas se ejecutan a través de saltos en el código y los argumentos de la matriz se pasan internamente mediante punteros a la memoria. Por lo tanto, cuando el compilador genera el código para una función interna, esa función espera que sus argumentos estén ubicados en la memoria.

Para funciones externas, el compilador no necesita permitir llamadas internas, por lo que permite que los argumentos se lean directamente desde calldata, ahorrando el paso de copia.

En cuanto a las mejores prácticas, debe usar externalsi espera que la función solo se llame externamente, y use publicsi necesita llamar a la función internamente. Casi nunca tiene sentido usar el this.f()patrón, ya que requiere un real CALLpara ejecutarse, lo cual es costoso. Además, pasar arreglos a través de este método sería mucho más costoso que pasarlos internamente.

Esencialmente, verá beneficios de rendimiento externalcada vez que solo llame a una función externamente y pase una gran cantidad de datos de llamada (por ejemplo, matrices grandes).

Ejemplos para diferenciar:

público - todos pueden acceder

externo: no se puede acceder internamente, solo externamente

interno: solo este contrato y los contratos derivados de él pueden acceder

privado: solo se puede acceder desde este contrato

Actualización para Solidez ^0.8

La respuesta de Tjaden es excelente, pero creo que merece una actualización para las últimas versiones de Solidity. Su fragmento de código ya no se compila. Recibe este error ahora:

La ubicación de los datos debe ser memoryo calldatapara el parámetro en función, pero no se proporcionó ninguno.

Esto se debe al nuevo requisito de ser explícito al usar tipos de referencia , como matrices. También memoryy calldataahora están permitidos en todas las funciones independientemente de su visibilidad.

Una reescritura sería algo como esto:

pragma solidity >=0.8.13;

contract ExternalPublicTest {
    function foo(uint[20] memory a) public pure returns (uint){
         return a[10]*2;
    }

    function bar(uint[20] calldata a) external pure returns (uint){
         return a[10]*2;
    }    
}

Como nota al margen, puede decodificar calldatavariables memorypero no al revés.

Reestructurando la respuesta anterior para mayor claridad:

pragma solidity^0.4.12;

contract Test {

    /*
    Cost: 496 Gas 
    This can be called internally or externally
    Since internal calls expects function arguements to be allocated to memory, solidity immediately
    copies array arguments to memory (This is what cost the additional gas.) 
    */
    function test(uint[20] a) public returns (uint) {
        return a[10] * 2;
    }

    /*
    Cost: Gas 261
    Doesnt allow internal calls, read directly from CALLDATA saving on the copying step(memory allocation).
    */
    function test(uint[20] a) external returns (uint) {
        return a[10] * 2;
    }


    /*
     Executed via JUMPs in code, array arguments are passed internally by pointers to memmory
      Function expects argument to be located in memory. 
     */
    function test(uint[20] a) internal returns (uint) {
        return a[10] * 2;
    }
}

• Las llamadas internas son las más económicas, ya que se ejecutan mediante código JUMP, pasando punteros a memoria.
• Las llamadas internas para funciones públicas son costosas porque las llamadas a funciones internas esperan que los argumentos se asignen a la memoria, ya que la función pública no sabe si la invocación es externa o interna, copia los argumentos en la memoria y, por lo tanto, es más costosa.

• Si sabe que la función solo se llamará externamente, useexternal

• Casi nunca tiene sentido usar el patrón this.f(), ya que requiere que se ejecute una LLAMADA real, lo cual es costoso.

Acabo de comprobar el resultado con el último compilador. Parece que la reducción del costo del gas se debe a la memoria frente a los datos de llamada, es decir, no importa si una función es externa o pública. Lo que importa es si la matriz de entrada es memoria o datos de llamada.

// SPDX-License-Identifier: MIT

pragma solidity 0.8.4;

contract ExternalPublicTest {
    function test(uint[20] memory a) public pure returns (uint){
         return a[10]*2;
    }

    function test2(uint[20] calldata a) public pure returns (uint){
         return a[10]*2;
    }    
}

respuesta sencilla

El publices equivalente a externalmás internal.

En otras palabras, ambos publicy externalpueden llamarse desde fuera de su contrato (como MetaMask), pero estos dos solo publicpueden llamarse desde otras funciones dentro de su contrato.

Debido a que publicotorga más acceso que external, la mejor práctica general es preferir external. Entonces puede considerar cambiar a publicsi comprende completamente las implicaciones de seguridad y diseño.

También tenga en cuenta que externalsignifica externo al contrato, no a la red. Tanto externallas publicfunciones como pueden llamarse desde otro contrato dentro de la misma transacción. Del documento:

Las funciones externas son parte de la interfaz del contrato, lo que significa que se pueden llamar desde otros contratos y mediante transacciones.

Por lo tanto external, no evita las llamadas reentrantes a la función. Para eso, uno puede usar ReentrancyGuard de OpenZeppelin , pero eso cuesta gasolina.

He probado con solidity 0.8.14

pragma solidity 0.8.14;
contract Test {
   function test(uint[2] calldata a) external pure returns (uint){
     return a[1]*2;
   }
}

como puede ver, el especificador de visibilidad de función utilizado es externo

pragma solidity 0.8.14;
contract Test {
   function test(uint[2] calldata a) public pure returns (uint){
     return a[1]*2;
   }
}

en este caso, el especificador de visibilidad de función utilizado es público

para ambos casos el gas consumido es 22116 (en remix) por lo que no hay diferencia entre externo y publico en cuanto al consumo de gas

Otra prueba:

pragma solidity 0.8.14;
contract Test1 {
  uint a;
  function test() external{
       a = 1;
  }
}

En este caso he probado una transacción que cambia el estado del contrato del contrato y el costo de ejecución es 43300

pragma solidity 0.8.14;
contract Test2 {
  uint a;    
  function test() public{
       a = 1;
  }
}

ejecutando la misma función pero cambiando de externo a público obtuve el mismo resultado: el costo de ejecución es igual a 43300

Entonces, en términos de consumo de gas, no vi ninguna diferencia.

Entonces, para los compiladores más recientes, una función externa es una función pública que obliga a que sus argumentos residan en calldata, mientras que una función pública es una función que es visible desde el exterior y permite que sus argumentos residan tanto en la memoria como en calldata.