Cómo utilizar Polygon zkEVM con Avail
Introducción
Embárquese en configurar su propia red Polygon zkEVM, aprovechando Avail como capa de disponibilidad de datos. Esta guía está diseñada para implementarse en la red de prueba Sepolia de Ethereum y para integrarse con la red de prueba Avail Goldberg. Para obtener una comprensión integral de Polygon zkEVM, revise laDocumentación del polígono zkEVM(se abre en una nueva pestaña).
En esta guía, realizará lo siguiente:
Requisitos previos
Asegúrese de haber instalado el siguiente software.
Los comandos de instalación se basan en Ubuntu 20.04 LTS:
| |||||||||||||
Software | Versión | ||||||||||||
Última versión LTS | |||||||||||||
Sistema operativo predeterminado | |||||||||||||
1.19 | |||||||||||||
El último | |||||||||||||
El último |
Requisitos de hardware
Tanto los probadores reales como los simulados son compatibles exclusivamente con arquitecturas x86. No están diseñados para funcionar en máquinas con arquitectura ARM, incluidos los dispositivos Apple Silicon, ni siquiera en entornos Dockerizados.
Componente | Requerimientos mínimos | Configuración recomendada | Instancia de AWS sugerida |
Probador simulado | CPU de 4 núcleos, 8 GB de RAM, 50 GB de SSD | CPU de 8 núcleos, 16 GB de RAM, 60 GB de SSD | r6a.xlarge |
verdadero probador | CPU de 96 núcleos, 768 GB de RAM, SSD de 120 GB | CPU de 96 núcleos, 1000 GB de RAM, SSD de 140 GB | r6a.24xgrande |
La ejecución del conjunto de soluciones Polygon zkEVM puede provocar problemas de almacenamiento, principalmente debido a un exceso de registros de Docker. Para mitigar esto, puede personalizar el comportamiento del demonio Docker consultando la primera respuesta.aquí(se abre en una nueva pestaña). Elija la configuración que mejor se adapte a sus necesidades.
Para una configuración devnet con crecimiento de estado limitado y registros de Docker, recomendamos un tamaño de disco mínimo de aproximadamente 50 GB.
Si planea ejecutar un probador real, es recomendable asignar un tamaño de disco mínimo de alrededor de 120 GB para su configuración devnet.
Tenga en cuenta que estas recomendaciones pueden variar según su caso de uso y requisitos específicos.
💡
CONSIDERACIONES ADICIONALES DE ALMACENAMIENTO En entornos de producción con un alto volumen de transacciones, sus requisitos de almacenamiento pueden aumentar significativamente. Se recomienda utilizar una solución de almacenamiento de datos similar a EBS para garantizar la escalabilidad, lo que le permitirá agregar más almacenamiento según sea necesario.
Detalles de la red
Antes de sumergirse en la configuración, asegúrese de tener los siguientes detalles de red:
Servicio | URL |
Explorador | |
RPC | |
Servicio de puente |
Inicie un zkEVM con tecnología disponible
⚠️
DESCARGO DE RESPONSABILIDAD DE USO
Los componentes del probador y del verificador mantienen sus garantías de seguridad originales. Sin embargo, tenga en cuenta que la verificación de la certificación de datos durante la secuenciación o cualquier aspecto validium-node
relacionado con la disponibilidad de datos en Avail no se ha sometido a una auditoría. Tenga cuidado al utilizar este programa. Se distribuye sin garantía alguna, ni garantía implícita de comerciabilidad o idoneidad para un propósito particular.
Tenga en cuenta que algunos aspectos de esta guía pueden diferir de la fuente original debido a la naturaleza única de la implementación de Avail validium. Para configuraciones y solución de problemas específicas del nodo zkEVM, consulte ladocumentación oficial del polígono(se abre en una nueva pestaña).
Implementar los contratos
Clona el
validium-contracts
repositorio e instala las dependencias:Configure el entorno y los parámetros de implementación:
Actualización
.env
según.env.example
..env.ejemplo
Complete
deploy_parameters.json
lo siguientedeploy_parameters.json.example
:Especifique la
trustedSequencer
dirección. Esta dirección representa el secuenciador responsable de secuenciar lotes.Defina la
trustedAggregator
dirección. Esta dirección representa el Agregador que se encarga de la presentación de pruebas.Llene los siguientes campos con las respectivas direcciones que controlarán los contratos:
admin
,zkEVMOwner
,timelockAddress
, yinitialZkEVMDeployerOwner
.Ingrese la clave privada del implementador en el
deployerPvtKey
campo.implementación/deploy_parameters.json
Ejecute scripts de implementación en la red Sepolia:
Deberías generar un
deploy_output.json
archivo.Verificar los contratos implementados:
💡
GENERAR UN NUEVO CONJUNTO DE CONTRATOS
Para crear un nuevo conjunto de contratos, puede emplear una nueva clave privada o incrementar el valor del salt
parámetro en su configuración. Después de realizar este cambio, simplemente vuelva a ejecutar los comandos de implementación para generar el nuevo conjunto de contratos.
Implementar el nodo
⚠️
FUNCIONALIDAD DE PROBADOR MOCK El Mock Prover no genera ninguna prueba de conocimiento cero. En cambio, simplemente valida cualquier estado raíz generado como correcto. El contrato de verificador simulado funciona de manera similar, aceptando todas las pruebas de validez sin verificación real.
Clona el
validium-node
repositorio para la configuración del nodo:Genere un archivo de almacén de claves de cuenta seguro para transacciones Ethereum L1:
Reemplácela
[your private key]
con la clave privada de su cuenta Ethereum L1.Reemplácela
[password to encrypt file]
con una contraseña utilizada para cifrar archivos. Esta contraseña debe pasarse al Nodo más tarde a través de la variable envZKEVM_NODE_ETHERMAN_PRIVATEKEYPASSWORD
.
Actualice los archivos de configuración para el nodo:
Modifique
test.avail.config.json
,test.node.config.toml
ytest.genesis.config.json
según los archivos de ejemplo proporcionados.
Cree la imagen de Docker e inicie el nodo:
Configurar el probador
Para cambiar al modo verificador real, modifique el
deploy_parameters.json
archivo:Utilice los siguientes comandos para descargar y descomprimir el archivo de configuración:
💡
TAMAÑO: ~70GB+ Acelere el proceso de descarga utilizando un descargador multiproceso como Axel.
Asegúrese de que
docker-compose.yml
incluya asignaciones de archivos adecuadas para la configuración del probador.Modifique
test.prover.config.json
para habilitar la funcionalidad del probador real:prueba.prover.config.json
Configurar el puente
El servicio de puente zkEVM es un microservicio que simplifica el puente entre L1 y L2 al reclamar automáticamente las transacciones L1 en L2 y generar las pruebas Merkle necesarias. Si bien es opcional para ejecutar Validium, mejora la facilidad de realizar transacciones puente.
El puente Nomad DA solo está operativo en Sepolia, lo que limita la certificación de datos de Validium a esta cadena. Alternativamente, puede simular la certificación de datos e implementarla en su cadena de bloques preferida.
Clona el repositorio puente:
Complete
config/config.local.toml
lo siguienteconfig.local.example.toml
:A menos que haya cambiado el archivo génesis, la dirección del puente L2 debería seguir siendo la misma.
A la dirección proporcionada de forma predeterminada en la configuración se le asigna ETH en la configuración de prueba de validación para la reclamación automática en L2. Si se utiliza una dirección diferente, es posible que se requiera ETH. De manera similar, en una configuración de producción donde ETH no se acuña arbitrariamente, deberá depositar fondos manualmente en la
zkevm-bridge-service
cuenta de reclamación automática.Parámetro
Valor de ejemplo
L1URL
"http://zkevm-mock-l1-network:8545"
GenBlockNumber
1
PolygonBridgeAddress
"0xff0EE8ea08cEf5cb4322777F5CC3E8A584B8A4A0"
PolygonZkEVMGlobalExitRootAddress
"0x2279B7A0a67DB372996a5FaB50D91eAA73d2eBe6"
L2PolygonBridgeAddresses
"0xff0EE8ea08cEf5cb4322777F5CC3E8A584B8A4A0"
Cree y ejecute la imagen de Docker usando los siguientes comandos:
Una vez que la imagen de Docker se está ejecutando, sirve como un microservicio para detectar transacciones puente L1 y L2. Puede comprobar si la API está activa accediendo al
/api
punto final.Generar pruebas Merkle : utilice el punto final /merkle-proof para generar las pruebas Merkle necesarias para transacciones puente.
Puntos finales adicionales : el microservicio proporciona otros puntos finales para diversas funcionalidades, como la detección de transacciones puente para cuentas específicas.
Actualización de código : si necesita modificar alguna parte del código, recuerde que cada cambio requiere una nueva compilación. Para actualizar y volver a ejecutar el servicio, ejecute los
make build-docker && make run
comandos.
Last updated