Introducción a los contratos inteligentes - Documentación Solidity 0.8.

17 25/9/22 22:15

! » Introducción a los contratos inteligentes

Introducción a los contratos inteligentes

Un Simple Contrato Inteligente

Comencemos con un ejemplo básico que establece el valor de una variable y la expone para que
puedan acceder otros contratos. Está bien si no lo en!endes todo ahora mismo, hablaremos en más
detalles más adelante.

Ejemplo de almacenamiento

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

contract SimpleStorage {
uint storedData;

function set(uint x) public {

storedData = x;
}

function get() public view returns (uint) {

return storedData;
}
}

La primera línea le indica que el código fuente está licenciado bajo la versión 3.0 de la GPL. Los
especificadores de licencia legibles por máquina son importantes en un entorno en el que la
publicación del código fuente es el predeterminado.

La siguiente línea especifica que el código fuente está escrito para Solidity versión 0.4.16, o una
versión más reciente del idioma hasta, pero sin incluir la versión 0.9.0. Esto es para garan!zar que el
contrato no se pueda compilar con una nueva versión (romper) del compilador, donde podría
comportarse de manera diferente. Los Pragmas son instrucciones comunes para los compiladores
sobre cómo tratar el código fuente (por ejemplo, pragma una vez).

A contract in the sense of Solidity is a collec!on of code (its func!ons) and data (its state) that
resides at a specific address on the Ethereum blockchain. The line uint storedData; declares a
state variable called storedData of type uint (unsigned integer of 256 bits). You can think of it as
a single slot in a database that you can query and alter by calling func!ons of the code that
manages the database. In this example, the contract defines the func!ons set and get that can
be used to modify or retrieve the value of the variable.

To access a member (like a state variable) of the current contract, you do not typically add the
this. prefix, you just access it directly via its name. Unlike in some other languages, omi"ng it is

not just a ma#er of style, it results in a completely different way to access the member, but more on
this later.

This contract does not do much yet apart from (due to the infrastructure built by Ethereum)
allowing anyone to store a single number that is accessible by anyone in the world without a
(feasible) way to prevent you from publishing this number. Anyone could call set again with a
different value and overwrite your number, but the number is s!ll stored in the history of the
blockchain. Later, you will see how you can impose access restric!ons so that only you can alter the
number.

" Advertencia

Tenga cuidado con el uso de texto Unicode, ya que los caracteres de aspecto similar (o incluso
idén!cos) pueden tener diferentes puntos de código y, como tales, se codifican como una matriz
de bytes diferente.

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 1 de 8
Introducción a los contratos inteligentes - Documentación Solidity 0.8.17 25/9/22 22:15

" Nota

Todos los iden!ficadores (nombres de contratos, nombres de funciones y nombres de variables)

están restringidos al conjunto de caracteres ASCII. Es posible almacenar datos codificados en
UTF-8 en variables de cadena.

Ejemplo de submoneda

El siguiente contrato implementa la forma más simple de una criptomoneda. El contrato solo
permite a su creador crear nuevas monedas (es posible que se produzcan diferentes esquemas de
emisión). Cualquiera puede enviarse monedas sin necesidad de registrarse con un nombre de
usuario y una contraseña, todo lo que necesita es un par de claves de Ethereum.

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.4;

contract Coin {
// The keyword "public" makes variables
// accessible from other contracts
address public minter;
mapping (address => uint) public balances;

// Events allow clients to react to specific

// contract changes you declare
event Sent(address from, address to, uint amount);

// Constructor code is only run when the contract

// is created
constructor() {
minter = msg.sender;
}

// Sends an amount of newly created coins to an address

// Can only be called by the contract creator
function mint(address receiver, uint amount) public {
require(msg.sender == minter);
balances[receiver] += amount;
}

// Errors allow you to provide information about

// why an operation failed. They are returned
// to the caller of the function.
error InsufficientBalance(uint requested, uint available);

// Sends an amount of existing coins

// from any caller to an address
function send(address receiver, uint amount) public {
if (amount > balances[msg.sender])
revert InsufficientBalance({
requested: amount,
available: balances[msg.sender]
});

balances[msg.sender] -= amount;
balances[receiver] += amount;
emit Sent(msg.sender, receiver, amount);
}
}

Este contrato introduce algunos conceptos nuevos, repasémoslos uno por uno.

The line address public minter; declares a state variable of type address. The address type is a
160-bit value that does not allow any arithme!c opera!ons. It is suitable for storing addresses of
contracts, or a hash of the public half of a keypair belonging to external accounts.

The keyword public automa!cally generates a func!on that allows you to access the current
value of the state variable from outside of the contract. Without this keyword, other contracts have
no way to access the variable. The code of the func!on generated by the compiler is equivalent to
the following (ignore external and view for now):

function minter() external view returns (address) { return minter; }

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 2 de 8
Introducción a los contratos inteligentes - Documentación Solidity 0.8.17 25/9/22 22:15

Podrías añadir una función como la anterior tú mismo, pero tendrías una función y una variable de
estado con el mismo nombre. No necesitas hacer esto, el compilador lo averigüe por !.

The next line, mapping (address => uint) public balances; also creates a public state variable, but
it is a more complex datatype. The mapping type maps addresses to unsigned integers.

Los mapeos se pueden ver como tablas hash que se inicializan virtualmente de tal manera que
todas las claves posibles existen desde el principio y se asignan a un valor cuya representación de
bytes es todos ceros. Sin embargo, no es posible obtener una lista de todas las claves de una
asignación, ni una lista de todos los valores. Graba lo que has añadido al mapeo o úsalo en un
contexto en el que no sea necesario. O mejor aún, mantenga una lista o u!lice un !po de datos más
adecuado.

The ge#er func!on created by the public keyword is more complex in the case of a mapping. It
looks like the following:

function balances(address account) external view returns (uint) {

return balances[account];
}

Puedes usar esta función para consultar el saldo de una sola cuenta.

The line event Sent(address from, address to, uint amount); declares an “event”, which is emi#ed
in the last line of the func!on send . Ethereum clients such as web applica!ons can listen for these
events emi#ed on the blockchain without much cost. As soon as it is emi#ed, the listener receives
the arguments from , to and amount , which makes it possible to track transac!ons.

To listen for this event, you could use the following JavaScript code, which uses web3.js to create
the Coin contract object, and any user interface calls the automa!cally generated balances
func!on from above:

Coin.Sent().watch({}, '', function(error, result) {

if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + result.args.to + ".");
console.log("Balances now:\n" +
"Sender: " + Coin.balances.call(result.args.from) +
"Receiver: " + Coin.balances.call(result.args.to));
}
})

The constructor is a special func!on that is executed during the crea!on of the contract and
cannot be called a%erwards. In this case, it permanently stores the address of the person crea!ng
the contract. The msg variable (together with tx and block ) is a special global variable that
contains proper!es which allow access to the blockchain. msg.sender is always the address where
the current (external) func!on call came from.

The func!ons that make up the contract, and that users and contracts can call are mint and send .

The mint func!on sends an amount of newly created coins to another address. The require
func!on call defines condi!ons that reverts all changes if not met. In this example,
require(msg.sender == minter); ensures that only the creator of the contract can call mint . In
general, the creator can mint as many tokens as they like, but at some point, this will lead to a
phenomenon called “overflow”. Note that because of the default Checked arithme!c, the
transac!on would revert if the expression balances[receiver] += amount; overflows, i.e., when
balances[receiver] + amount in arbitrary precision arithme!c is larger than the maximum value of
uint ( 2**256 - 1 ). This is also true for the statement balances[receiver] += amount; in the
func!on send .

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 3 de 8
Introducción a los contratos inteligentes - Documentación Solidity 0.8.17 25/9/22 22:15

Errors allow you to provide more informa!on to the caller about why a condi!on or opera!on
failed. Errors are used together with the revert statement. The revert statement uncondi!onally
aborts and reverts all changes similar to the require func!on, but it also allows you to provide the
name of an error and addi!onal data which will be supplied to the caller (and eventually to the
front-end applica!on or block explorer) so that a failure can more easily be debugged or reacted
upon.

The send func!on can be used by anyone (who already has some of these coins) to send coins to
anyone else. If the sender does not have enough coins to send, the if condi!on evaluates to true.
As a result, the revert will cause the opera!on to fail while providing the sender with error details
using the InsufficientBalance error.

" Nota

Si u!liza este contrato para enviar monedas a una dirección, no verá nada cuando mire esa
dirección en un explorador de cadenas de bloques, porque el registro en el que envió monedas y
los saldos cambiados solo se almacenan en el almacenamiento de datos de este contrato de
monedas en par!cular. Mediante el uso de eventos, puede crear un "explorador de cadenas de
bloques" que rastree las transacciones y los saldos de su nueva moneda, pero !ene que
inspeccionar la dirección del contrato de la moneda y no las direcciones de los propietarios de la
moneda.

Conceptos básicos de la cadena de bloques

Las cadenas de bloques como concepto no son demasiado di&ciles de entender para los
programadores. La razón es que la mayoría de las complicaciones (minería, hash, criptogra&a de
curva elíp!ca, redes de punto a punto, etc.) están ahí para proporcionar un cierto conjunto de
caracterís!cas y promesas para la plataforma. Una vez que aceptas estas caracterís!cas como se
dan, no !enes que preocuparte por la tecnología subyacente, ¿o !enes que saber cómo funciona
AWS de Amazon internamente para usarla?

Transacciones

Una cadena de bloques es una base de datos transaccional compar!da a nivel mundial. Esto
significa que todo el mundo puede leer las entradas de la base de datos con solo par!cipar en la
red. Si quieres cambiar algo en la base de datos, !enes que crear una llamada transacción que !ene
que ser aceptada por todos los demás. La palabra transacción implica que el cambio que desea
hacer (suponga que desea cambiar dos valores al mismo !empo) no se realiza en absoluto o se
aplica por completo. Además, mientras su transacción se aplica a la base de datos, ninguna otra
transacción puede alterarla.

Por ejemplo, imagina una tabla que enumere los saldos de todas las cuentas en una moneda
electrónica. Si se solicita una transferencia de una cuenta a otra, la naturaleza transaccional de la
base de datos garan!za que si la can!dad se resta de una cuenta, siempre se añade a la otra cuenta.
Si por alguna razón no es posible añadir la can!dad a la cuenta de des!no, la cuenta de origen
tampoco se modifica.

Además, el remitente (creador) siempre firma criptográficamente una transacción. Esto hace que
sea sencillo proteger el acceso a modificaciones específicas de la base de datos. En el ejemplo de la
moneda electrónica, un simple cheque garan!za que solo la persona que !ene las llaves de la
cuenta pueda transferir dinero de ella.

Bloques

Un obstáculo importante que hay que superar es lo que (en términos de Bitcoin) se llama un
"ataque de doble gasto": ¿Qué sucede si existen dos transacciones en la red que ambas quieren
vaciar una cuenta? Solo una de las transacciones puede ser válida, normalmente la que se acepta
primero. El problema es que "primero" no es un término obje!vo en una red de igual a igual.

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 4 de 8
Introducción a los contratos inteligentes - Documentación Solidity 0.8.17 25/9/22 22:15

La respuesta abstracta a esto es que no !enes que preocuparte. Se seleccionará un orden de

transacciones aceptado a nivel mundial para usted, resolviendo el conflicto. Las transacciones se
agruparán en lo que se llama un "bloque" y luego se ejecutarán y distribuirán entre todos los nodos
par!cipantes. Si dos transacciones se contradicen, la que termina siendo la segunda será rechazada
y no pasará a formar parte del bloqueo.

Estos bloques forman una secuencia lineal en el !empo y de ahí se deriva la palabra "blockchain".
Los bloques se añaden a la cadena a intervalos bastante regulares; para Ethereum, esto es
aproximadamente cada 17 segundos.

Como parte del "mecanismo de selección de pedidos" (que se llama "minería"), puede suceder que
los bloques se reviertan de vez en cuando, pero solo en la "punta" de la cadena. Cuantos más
bloques se añadan encima de un bloque en par!cular, menos probable será que este bloque se
revierta. Así que podría ser que tus transacciones se reviertan e incluso se eliminen de la cadena de
bloques, pero cuanto más esperes, menos probable será.

" Nota

No se garan!za que las transacciones se incluyan en el siguiente bloque o en ningún bloque

futuro específico, ya que no depende del remitente de una transacción, sino de los mineros
determinar en qué bloque se incluye la transacción.

Si desea programar futuras llamadas de su contrato, puede u!lizar una herramienta de

automa!zación de contratos inteligentes o un servicio de oráculo.

La máquina virtual Ethereum

DESCRIPCIÓN

La máquina virtual Ethereum o EVM es el entorno de !empo de ejecución para contratos

inteligentes en Ethereum. No solo está en sandbox, sino que en realidad está completamente
aislado, lo que significa que el código que se ejecuta dentro de la EVM no !ene acceso a la red, al
sistema de archivos u otros procesos. Los contratos inteligentes incluso !enen acceso limitado a
otros contratos inteligentes.

Cuentas

Hay dos !pos de cuentas en Ethereum que comparten el mismo espacio de direcciones: cuentas
externas que están controladas por pares de claves público-privadas (es decir, humanos) y cuentas
de contrato que están controladas por el código almacenado junto con la cuenta.

La dirección de una cuenta externa se determina a par!r de la clave pública, mientras que la
dirección de un contrato se determina en el momento en que se crea el contrato (se deriva de la
dirección del creador y del número de transacciones enviadas desde esa dirección, la llamada
"nonce").

Independientemente de si la cuenta almacena o no el código, el EVM trata los dos !pos por igual.

Cada cuenta !ene un almacén de clave-valor persistente que asigna palabras de 256 bits a palabras
de 256 bits llamadas almacenamiento.

Furthermore, every account has a balance in Ether (in “Wei” to be exact, 1 ether is 10**18 wei )
which can be modified by sending transac!ons that include Ether.

Transacciones

Una transacción es un mensaje que se envía de una cuenta a otra (que puede ser la misma o estar
vacía, ver a con!nuación). Puede incluir datos binarios (que se llama "carga ú!l") y Ether.

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 5 de 8
Introducción a los contratos inteligentes - Documentación Solidity 0.8.17 25/9/22 22:15

Si la cuenta de des!no con!ene código, ese código se ejecuta y la carga ú!l se proporciona como
datos de entrada.

Si la cuenta de des!no no está establecida (la transacción no !ene un des!natario o el des!natario

está establecido en null ), la transacción crea un nuevo contrato. Como ya se mencionó, la
dirección de ese contrato no es la dirección cero, sino una dirección derivada del remitente y su
número de transacciones enviadas (la "nuna"). La carga ú!l de dicha transacción de creación de
contrato se toma como código de bytes EVM y se ejecuta. Los datos de salida de esta ejecución se
almacenan permanentemente como código del contrato. Esto significa que para crear un contrato,
no envías el código real del contrato, sino, de hecho, el código que devuelve ese código cuando se
ejecuta.

" Nota

Mientras se crea un contrato, su código sigue vacío. Debido a eso, no debe volver a llamar al
contrato en construcción hasta que su constructor haya terminado de ejecutarlo.

Gasolina

Al crear, a cada transacción se le cobra una cierta can!dad de gas que !ene que ser pagada por el
originador de la transacción ( tx.origin ). Mientras el EVM ejecuta la transacción, el gas se agota
gradualmente de acuerdo con reglas específicas. Si el gas se agota en algún momento (es decir, sería
nega!vo), se ac!va una excepción fuera de gas, que pone fin a la ejecución y devuelve todas las
modificaciones realizadas al estado en el marco de llamada actual.

Este mecanismo incen!va el uso económico del !empo de ejecución de EVM y también compensa
a los ejecutores de EVM (es decir, mineros / apostadores) por su trabajo. Dado que cada bloque
!ene una can!dad máxima de gas, también limita la can!dad de trabajo necesario para validar un
bloque.

The gas price is a value set by the originator of the transac!on, who has to pay gas_price * gas up
front to the EVM executor. If some gas is le% a%er execu!on, it is refunded to the transac!on
originator. In case of an excep!on that reverts changes, already used up gas is not refunded.

Dado que los ejecutores de EVM pueden optar por incluir una transacción o no, los remitentes de
transacciones no pueden abusar del sistema estableciendo un precio bajo del gas.

Almacenamiento, memoria y la pila

La máquina virtual Ethereum !ene tres áreas en las que puede almacenar datos: almacenamiento,
memoria y pila.

Cada cuenta !ene un área de datos llamada almacenamiento, que es persistente entre las llamadas
a funciones y las transacciones. El almacenamiento es un almacén de valores clave que asigna
palabras de 256 bits a palabras de 256 bits. No es posible enumerar el almacenamiento desde
dentro de un contrato, es compara!vamente costoso de leer, y aún más para inicializar y modificar
el almacenamiento. Debido a este coste, debe minimizar lo que almacena en el almacenamiento
persistente a lo que el contrato necesita ejecutar. Almacene datos como cálculos derivados,
almacenamiento en caché y agregados fuera del contrato. Un contrato no puede leer ni escribir en
ningún almacén aparte del suyo.

La segunda área de datos se llama memoria, de la cual un contrato ob!ene una instancia recién
borrada para cada llamada de mensaje. La memoria es lineal y se puede abordar a nivel de bytes,
pero las lecturas están limitadas a un ancho de 256 bits, mientras que las escrituras pueden tener 8
bits o 256 bits de ancho. La memoria se expande con una palabra (256 bits), al acceder (ya sea
leyendo o escribiendo) a una palabra de memoria previamente no tocada (es decir, cualquier
desplazamiento dentro de una palabra). En el momento de la expansión, se debe pagar el coste del
gas. La memoria es más costosa cuanto más grande crece (se escala cuadra!camente).

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 6 de 8
Introducción a los contratos inteligentes - Documentación Solidity 0.8.17 25/9/22 22:15

La EVM no es una máquina de registro, sino una máquina de pila, por lo que todos los cálculos se
realizan en un área de datos llamada pila. Tiene un tamaño máximo de 1024 elementos y con!ene
palabras de 256 bits. El acceso a la pila se limita al extremo superior de la siguiente manera: es
posible copiar uno de los 16 elementos superiores a la parte superior de la pila o intercambiar el
elemento superior por uno de los 16 elementos que hay debajo. Todas las demás operaciones
toman los dos elementos más altos (o uno, o más, dependiendo de la operación) de la pila y
empujan el resultado a la pila. Por supuesto, es posible mover elementos de la pila al
almacenamiento o a la memoria para obtener un acceso más profundo a la pila, pero no es posible
acceder a elementos arbitrarios más profundos en la pila sin eliminar primero la parte superior de la
pila.

Conjunto de instrucciones

El conjunto de instrucciones de la EVM se man!ene mínimo para evitar implementaciones

incorrectas o inconsistentes que podrían causar problemas de consenso. Todas las instrucciones
funcionan en el !po de datos básico, palabras de 256 bits o en cortes de memoria (u otras matrices
de bytes). Las operaciones aritmé!cas, de bits, lógicas y de comparación habituales están presentes.
Los saltos condicionales e incondicionales son posibles. Además, los contratos pueden acceder a las
propiedades relevantes del bloque actual, como su número y marca de !empo.

Para obtener una lista completa, consulte la lista de códigos de operación como parte de la
documentación de ensamblaje en línea.

Llamadas de mensajes

Los contratos pueden llamar a otros contratos o enviar Ether a cuentas no contractuales por medio
de llamadas por mensaje. Las llamadas de mensajes son similares a las transacciones, ya que !enen
una fuente, un des!no, una carga ú!l de datos, éter, gas y datos de retorno. De hecho, cada
transacción consiste en una llamada de mensaje de nivel superior que a su vez puede crear más
llamadas de mensaje.

Un contrato puede decidir cuánto de su gas restante debe enviarse con la llamada de mensaje
interno y cuánto quiere retener. Si se produce una excepción de salida de gas en la llamada interna
(o en cualquier otra excepción), esto se indicará mediante un valor de error puesto en la pila. En
este caso, solo se agota el gas enviado junto con la llamada. En Solidity, el contrato de llamada
causa una excepción manual de forma predeterminada en tales situaciones, de modo que las
excepciones "abubble" la pila de llamadas.

Como ya se ha dicho, el contrato llamado (que puede ser el mismo que el que llama) recibirá una
instancia de memoria recién borrada y tendrá acceso a la carga ú!l de la llamada, que se
proporcionará en un área separada llamada datos de llamada. Una vez que haya terminado la
ejecución, puede devolver datos que serán almacenados en una ubicación en la memoria de la
persona que llama preasignada por la persona que llama. Todas estas llamadas son totalmente
sincrónicas.

Las llamadas se limitan a una profundidad de 1024, lo que significa que para operaciones más
complejas, se deben preferir los bucles a las llamadas recursivas. Además, solo la 63/64 parte del
gas se puede reenviar en una llamada de mensaje, lo que provoca un límite de profundidad de poco
menos de 1000 en la prác!ca.

Llamada de delegados y bibliotecas

There exists a special variant of a message call, named delegatecall which is iden!cal to a message
call apart from the fact that the code at the target address is executed in the context (i.e. at the
address) of the calling contract and msg.sender and msg.value do not change their values.

Esto significa que un contrato puede cargar código dinámicamente desde una dirección diferente
en !empo de ejecución. El almacenamiento, la dirección actual y el saldo todavía se refieren al
contrato de llamada, solo se toma el código de la dirección llamada.

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 7 de 8
Introducción a los contratos inteligentes - Documentación Solidity 0.8.17 25/9/22 22:15

Esto hace posible implementar la función "biblioteca" en Solidity: Código de biblioteca reu!lizable
que se puede aplicar al almacenamiento de un contrato, por ejemplo, para implementar una
estructura de datos compleja.

Registros

Es posible almacenar datos en una estructura de datos especialmente indexada que se asigna hasta
el nivel de bloque. Solidity u!liza esta función llamada registros para implementar eventos. Los
contratos no pueden acceder a los datos de registro después de que se hayan creado, pero se
puede acceder a ellos de manera eficiente desde fuera de la cadena de bloques. Dado que parte de
los datos de registro se almacenan en filtros de floración, es posible buscar estos datos de una
manera eficiente y criptográficamente segura, por lo que los compañeros de red que no descargan
toda la cadena de bloques (los llamados "clientes ligeros") aún pueden encontrar estos registros.

Crear

Los contratos incluso pueden crear otros contratos u!lizando un código de operación especial (es
decir, no simplemente llaman a la dirección cero como lo haría una transacción). La única diferencia
entre estas llamadas de creación y las llamadas de mensajes normales es que los datos de la carga
ú!l se ejecutan y el resultado se almacena como código y la persona que llama / creadora recibe la
dirección del nuevo contrato en la pila.

Desactivar y autodestruir

La única forma de eliminar el código de la cadena de bloques es cuando un contrato en esa

dirección realiza la operación de selfdestruct . El Ether restante almacenado en esa dirección se
envía a un des!no designado y luego el almacenamiento y el código se eliminan del estado. Eliminar
el contrato en teoría suena como una buena idea, pero es potencialmente peligroso, como si
alguien enviara Ether a contratos eliminados, el Ether se pierde para siempre.

" Advertencia

Even if a contract is removed by selfdestruct , it is s!ll part of the history of the blockchain and
probably retained by most Ethereum nodes. So using selfdestruct is not the same as dele!ng
data from a hard disk.

" Nota

Even if a contract’s code does not contain a call to selfdestruct , it can s!ll perform that
opera!on using delegatecall or callcode .

Si desea desac!var sus contratos, debe desac!varlos cambiando algún estado interno que haga
que todas las funciones se reviertan. Esto hace que sea imposible usar el contrato, ya que devuelve
Ether inmediatamente.

Contratos precompilados

There is a small set of contract addresses that are special: The address range between 1 and
(including) 8 contains “precompiled contracts” that can be called as any other contract but their
behaviour (and their gas consump!on) is not defined by EVM code stored at that address (they do
not contain code) but instead is implemented in the EVM execu!on environment itself.

Different EVM-compa!ble chains might use a different set of precompiled contracts. It might also
be possible that new precompiled contracts are added to the Ethereum main chain in the future,
but you can reasonably expect them to always be in the range between 1 and 0xffff (inclusive).

https://docs.soliditylang.org/en/v0.8.17/introduction-to-smart-contracts.html Página 8 de 8