Posibilidades futuras del protocolo Ethereum: prosperidad
El diseño del protocolo de Ethereum tiene muchos "detalles" que son cruciales para su éxito. Aproximadamente la mitad del contenido se refiere a diferentes tipos de mejoras de EVM, mientras que el resto está compuesto por varios temas de nicho, que es el significado de "prosperidad".
Prosperidad: objetivo clave
Convertir EVM en un "estado final" de alto rendimiento y estabilidad
Introducir la abstracción de cuentas en el protocolo, permitiendo a todos los usuarios disfrutar de cuentas más seguras y convenientes.
Optimizar la economía de tarifas de transacción, mejorar la escalabilidad y reducir el riesgo al mismo tiempo.
Explorar la criptografía avanzada para mejorar significativamente Ethereum a largo plazo.
mejora de EVM
¿Qué problema se resolvió?
Actualmente, el EVM es difícil de analizar estáticamente, lo que dificulta la creación de implementaciones eficientes, la verificación formal del código y la realización de una mayor escalabilidad. Además, la eficiencia del EVM es baja, lo que dificulta la implementación de muchas formas de criptografía avanzada, a menos que se soporte explícitamente a través de precompilaciones.
¿Qué es y cómo funciona?
El primer paso en la hoja de ruta de mejora de EVM actual es el formato de objeto EVM (EOF), que se planea incluir en la próxima bifurcación dura. EOF es una serie de EIP que especifica una nueva versión del código EVM, con muchas características únicas, siendo la más notable:
El código ( es ejecutable, pero no se puede leer desde el EVM. ) y los datos ( son legibles, pero no se pueden ejecutar ).
Prohibir redirecciones dinámicas, solo permitir redirecciones estáticas
El código EVM ya no puede observar la información relacionada con el combustible.
Se ha añadido un nuevo mecanismo de subrutina explícita.
Los contratos antiguos seguirán existiendo y se podrán crear, aunque eventualmente pueden ser descontinuados gradualmente, y los contratos antiguos ( incluso pueden ser forzados a convertirse en código EOF ). Los nuevos contratos se beneficiarán de las mejoras de eficiencia que trae EOF: primero, mediante un bytecode ligeramente reducido gracias a las características de subrutinas, y luego, con nuevas funciones específicas de EOF o costos de gas reducidos.
Después de la introducción de EOF, las actualizaciones adicionales se vuelven más fáciles, y actualmente el desarrollo más completo es la extensión aritmética del módulo EVM (EVM-MAX). EVM-MAX crea un conjunto de nuevas operaciones específicamente para la operación de módulo y las coloca en un nuevo espacio de memoria que no puede ser accedido por otros códigos de operación, lo que hace posible el uso de optimizaciones como la multiplicación de Montgomery.
Una idea más reciente es combinar EVM-MAX con la característica de múltiples datos de una sola instrucción (SIMD), SIMD como un concepto de Ethereum ha existido durante mucho tiempo, propuesto por primera vez por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos las funciones hash, STARKs de 32 bits y criptografía basada en rejillas, la combinación de EVM-MAX y SIMD hace que estas dos escalas orientadas al rendimiento sean una pareja natural.
Enlace de investigación existente
EOF:
EVM-MAX:
SIMD:
Trabajo restante y compensaciones
Actualmente, se planea incluir EOF en la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento---en bifurcaciones duras anteriores, algunas funciones fueron eliminadas temporalmente, pero hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura al EVM deberá realizarse sin EOF, aunque es posible, podría ser más difícil.
El principal compromiso de EVM radica en la complejidad de L1 y la complejidad de la infraestructura. EOF es una gran cantidad de código que necesita ser agregado a la implementación de EVM, y la verificación de código estático también es relativamente compleja. Sin embargo, a cambio, podemos simplificar los lenguajes de alto nivel, simplificar la implementación de EVM y otros beneficios. Se puede decir que la hoja de ruta para la mejora continua de Ethereum L1 debería incluir y construirse sobre EOF.
Una tarea importante que debe realizarse es implementar funciones similares a EVM-MAX + SIMD y realizar pruebas de referencia sobre el consumo de gas de varias operaciones criptográficas.
¿Cómo interactuar con otras partes del plan?
L1 ajusta su EVM para que L2 también pueda realizar ajustes correspondientes más fácilmente. Si ambos no se sincronizan, puede haber incompatibilidades que traigan efectos adversos. Además, EVM-MAX y SIMD pueden reducir los costos de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita el reemplazo de más precompilados con código EVM que puede ejecutar las mismas tareas, lo que probablemente no afecte significativamente la eficiencia.
abstracción de cuentas
¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden verificar de una manera: mediante firma ECDSA. Inicialmente, la abstracción de cuentas tenía como objetivo ir más allá de esto, permitiendo que la lógica de verificación de cuentas sea cualquier código EVM. Esto puede habilitar una serie de aplicaciones:
Cambiar a criptografía resistente a cuántica
Rotar las claves antiguas ( se considera ampliamente una práctica de seguridad recomendada )
Billetera de múltiples firmas y billetera de recuperación social
Utilizar una clave para operaciones de bajo valor, utilizar otra clave ( o un conjunto de claves ) para operaciones de alto valor
Permitir que el protocolo de privacidad funcione sin intermediarios, reduciendo significativamente su complejidad y eliminando un punto de dependencia central clave.
Desde que se propuso la abstracción de cuentas en 2015, su objetivo también se ha ampliado para incluir una gran cantidad de "objetivos de conveniencia", por ejemplo, una cuenta que no tiene ETH pero que posee algunos ERC20 puede usar ERC20 para pagar el gas.
MPC( el cálculo multiparte ) es una tecnología con 40 años de historia, utilizada para dividir claves en múltiples partes y almacenarlas en varios dispositivos, utilizando técnicas criptográficas para generar firmas, sin necesidad de combinar directamente estas partes de clave.
EIP-7702 es una propuesta que se planea introducir en la próxima bifurcación dura. EIP-7702 es el resultado de una creciente conciencia sobre la conveniencia de proporcionar abstracción de cuentas para beneficiar a todos los usuarios (, incluidos los usuarios de EOA ), y tiene como objetivo mejorar la experiencia de todos los usuarios a corto plazo y evitar la división en dos ecosistemas.
Este trabajo comenzó con EIP-3074 y finalmente se convirtió en EIP-7702. EIP-7702 ofrece la "funcionalidad conveniente" de la abstracción de cuentas a todos los usuarios, incluidos los EOA( de hoy, es decir, cuentas controladas por firmas ECDSA).
Aunque algunos desafíos (, especialmente el desafío de "conveniencia" ), pueden ser resueltos mediante tecnologías progresivas como el cálculo multiparte o el EIP-7702, el principal objetivo de seguridad de la propuesta de abstracción de cuentas inicialmente presentada solo puede lograrse retrocediendo y resolviendo el problema original: permitir que el código de contrato inteligente controle la validación de transacciones. La razón por la cual esto aún no se ha logrado radica en la implementación segura, lo cual es un desafío.
¿Qué es y cómo funciona?
El núcleo de la abstracción de cuentas es simple: permite que los contratos inteligentes inicien transacciones, y no solo EOA. Toda la complejidad proviene de implementar esto de una manera que sea amigable para el mantenimiento de redes descentralizadas y prevenir ataques de denegación de servicio.
Un desafío clave típico es el problema de múltiples fallos:
Si hay 1000 funciones de verificación de cuentas que dependen de un único valor S, y el valor S actual hace que todas las transacciones en el pool de memoria sean válidas, entonces una única transacción que invierta el valor de S podría hacer que todas las otras transacciones en el pool de memoria sean inválidas. Esto permite que un atacante envíe transacciones basura al pool de memoria a un costo muy bajo, bloqueando así los recursos de los nodos de la red.
Tras años de esfuerzo, con el objetivo de expandir las funcionalidades mientras se limita el riesgo de denegación de servicio (DoS), finalmente se llegó a una solución para implementar "abstracción ideal de cuentas": ERC-4337.
El funcionamiento de ERC-4337 divide el procesamiento de las operaciones del usuario en dos fases: verificación y ejecución. Todas las verificaciones se procesan primero, y todas las ejecuciones se procesan después. En el pool de memoria, solo se aceptarán las operaciones del usuario cuya fase de verificación solo involucre su propia cuenta y no lea variables de entorno. Esto puede prevenir ataques de fallos múltiples. Además, se imponen estrictos límites de gas en el paso de verificación.
ERC-4337 fue diseñado como un estándar de protocolo adicional (ERC), porque en ese momento los desarrolladores de clientes de Ethereum se centraban en la fusión (Merge), sin energía adicional para manejar otras funciones. Por eso, ERC-4337 utiliza un objeto llamado operación de usuario, en lugar de transacciones convencionales. Sin embargo, recientemente nos hemos dado cuenta de la necesidad de escribir al menos parte de su contenido en el protocolo.
Las dos razones clave son las siguientes:
EntryPoint como la ineficiencia inherente del contrato: cada paquete tiene un costo fijo de aproximadamente 100,000 gas, además de miles de gas adicionales por cada operación de usuario.
Asegurar la necesidad de las propiedades de Ethereum: como la lista de inclusión creada que garantiza la necesidad de ser transferida a la cuenta de usuarios abstractos.
Además, ERC-4337 también ha ampliado dos funciones:
Agentes de pago ( Paymasters ): permite que una cuenta pague tarifas en nombre de otra cuenta, lo que viola la regla de que durante la fase de verificación solo se puede acceder a la cuenta del remitente. Por lo tanto, se introdujo un tratamiento especial para garantizar la seguridad del mecanismo de agentes de pago.
Agregadores(: Apoya funciones de agregación de firmas, como la agregación BLS o la agregación basada en SNARK. Esto es necesario para lograr la máxima eficiencia de datos en Rollup.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
)# Enlace de investigación existente
Discurso sobre la historia de la abstracción de cuentas:
ERC-4337:
EIP-7702:
El código BLSWallet ### utiliza la función de agregación (:
EIP-7562) escritura de la cuenta abstracta del protocolo (:
EIP-7701) cuenta abstracta de protocolo de escritura basado en EOF (:
)# El trabajo restante y las compensaciones
Actualmente, lo que se necesita resolver principalmente es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas que ha ganado popularidad recientemente es el EIP-7701, que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una sección de código separada para la verificación; si la cuenta establece esta sección de código, se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.
El encanto de este método radica en que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas locales:
Incluir EIP-4337 como parte del protocolo
Un nuevo tipo de EOA, donde el algoritmo de firma es la ejecución de código EVM
Si comenzamos estableciendo límites estrictos sobre la complejidad del código ejecutable durante el período de verificación---no se permite el acceso al estado externo, e incluso el límite de gas establecido inicialmente es tan bajo que es ineficaz para aplicaciones de resistencia cuántica o protección de la privacidad---entonces la seguridad de este enfoque es muy clara: simplemente reemplazar la verificación ECDSA por la ejecución de código EVM que requiere un tiempo similar.
Sin embargo, con el tiempo, necesitamos flexibilizar estos límites, ya que permitir que las aplicaciones de protección de la privacidad funcionen sin intermediarios, así como la resistencia cuántica, son muy importantes. Para ello, necesitamos encontrar formas más flexibles de abordar el riesgo de denegación de servicio ###DoS(, sin requerir que los pasos de verificación sean extremadamente simplistas.
La principal consideración parece ser "escribir rápidamente una solución que satisfaga a menos personas" frente a "esperar más tiempo para posiblemente obtener una solución más ideal", siendo el enfoque ideal posiblemente algún tipo de método híbrido. Un método híbrido podría ser escribir más rápidamente algunos casos de uso y dejar más tiempo para explorar otros casos de uso. Otro enfoque sería desplegar primero una versión más ambiciosa de abstracción de cuentas en L2. Sin embargo, el desafío que enfrenta esto es que el equipo de L2 necesita tener plena confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para asegurar que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.
Otra aplicación que aún necesitamos considerar claramente son las cuentas de almacenamiento de claves, que almacenan el estado relacionado con la cuenta en L1 o L2 dedicado, pero pueden estar en L1 y en cualquier lugar.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
25 me gusta
Recompensa
25
6
Republicar
Compartir
Comentar
0/400
AllInAlice
· 07-18 02:48
BTC lleva el camino hacia nuevos máximos
Ver originalesResponder0
BlockchainWorker
· 07-16 06:08
El cambio requiere tiempo
Ver originalesResponder0
TokenDustCollector
· 07-15 04:37
EVM necesita urgentemente mejorar su eficiencia
Ver originalesResponder0
WalletsWatcher
· 07-15 04:36
La baja barrera de entrada es clave.
Ver originalesResponder0
SchrodingerPrivateKey
· 07-15 04:35
Actualizar EVM es importante
Ver originalesResponder0
SelfCustodyIssues
· 07-15 04:13
Ver con buenos ojos la nueva ruta de actualización
Hoja de ruta de la prosperidad de Ethereum: actualización de EVM, abstracción de cuentas y optimización de EIP-1559
Posibilidades futuras del protocolo Ethereum: prosperidad
El diseño del protocolo de Ethereum tiene muchos "detalles" que son cruciales para su éxito. Aproximadamente la mitad del contenido se refiere a diferentes tipos de mejoras de EVM, mientras que el resto está compuesto por varios temas de nicho, que es el significado de "prosperidad".
Prosperidad: objetivo clave
mejora de EVM
¿Qué problema se resolvió?
Actualmente, el EVM es difícil de analizar estáticamente, lo que dificulta la creación de implementaciones eficientes, la verificación formal del código y la realización de una mayor escalabilidad. Además, la eficiencia del EVM es baja, lo que dificulta la implementación de muchas formas de criptografía avanzada, a menos que se soporte explícitamente a través de precompilaciones.
¿Qué es y cómo funciona?
El primer paso en la hoja de ruta de mejora de EVM actual es el formato de objeto EVM (EOF), que se planea incluir en la próxima bifurcación dura. EOF es una serie de EIP que especifica una nueva versión del código EVM, con muchas características únicas, siendo la más notable:
Los contratos antiguos seguirán existiendo y se podrán crear, aunque eventualmente pueden ser descontinuados gradualmente, y los contratos antiguos ( incluso pueden ser forzados a convertirse en código EOF ). Los nuevos contratos se beneficiarán de las mejoras de eficiencia que trae EOF: primero, mediante un bytecode ligeramente reducido gracias a las características de subrutinas, y luego, con nuevas funciones específicas de EOF o costos de gas reducidos.
Después de la introducción de EOF, las actualizaciones adicionales se vuelven más fáciles, y actualmente el desarrollo más completo es la extensión aritmética del módulo EVM (EVM-MAX). EVM-MAX crea un conjunto de nuevas operaciones específicamente para la operación de módulo y las coloca en un nuevo espacio de memoria que no puede ser accedido por otros códigos de operación, lo que hace posible el uso de optimizaciones como la multiplicación de Montgomery.
Una idea más reciente es combinar EVM-MAX con la característica de múltiples datos de una sola instrucción (SIMD), SIMD como un concepto de Ethereum ha existido durante mucho tiempo, propuesto por primera vez por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos las funciones hash, STARKs de 32 bits y criptografía basada en rejillas, la combinación de EVM-MAX y SIMD hace que estas dos escalas orientadas al rendimiento sean una pareja natural.
Enlace de investigación existente
Trabajo restante y compensaciones
Actualmente, se planea incluir EOF en la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento---en bifurcaciones duras anteriores, algunas funciones fueron eliminadas temporalmente, pero hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura al EVM deberá realizarse sin EOF, aunque es posible, podría ser más difícil.
El principal compromiso de EVM radica en la complejidad de L1 y la complejidad de la infraestructura. EOF es una gran cantidad de código que necesita ser agregado a la implementación de EVM, y la verificación de código estático también es relativamente compleja. Sin embargo, a cambio, podemos simplificar los lenguajes de alto nivel, simplificar la implementación de EVM y otros beneficios. Se puede decir que la hoja de ruta para la mejora continua de Ethereum L1 debería incluir y construirse sobre EOF.
Una tarea importante que debe realizarse es implementar funciones similares a EVM-MAX + SIMD y realizar pruebas de referencia sobre el consumo de gas de varias operaciones criptográficas.
¿Cómo interactuar con otras partes del plan?
L1 ajusta su EVM para que L2 también pueda realizar ajustes correspondientes más fácilmente. Si ambos no se sincronizan, puede haber incompatibilidades que traigan efectos adversos. Además, EVM-MAX y SIMD pueden reducir los costos de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita el reemplazo de más precompilados con código EVM que puede ejecutar las mismas tareas, lo que probablemente no afecte significativamente la eficiencia.
abstracción de cuentas
¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden verificar de una manera: mediante firma ECDSA. Inicialmente, la abstracción de cuentas tenía como objetivo ir más allá de esto, permitiendo que la lógica de verificación de cuentas sea cualquier código EVM. Esto puede habilitar una serie de aplicaciones:
Permitir que el protocolo de privacidad funcione sin intermediarios, reduciendo significativamente su complejidad y eliminando un punto de dependencia central clave.
Desde que se propuso la abstracción de cuentas en 2015, su objetivo también se ha ampliado para incluir una gran cantidad de "objetivos de conveniencia", por ejemplo, una cuenta que no tiene ETH pero que posee algunos ERC20 puede usar ERC20 para pagar el gas.
MPC( el cálculo multiparte ) es una tecnología con 40 años de historia, utilizada para dividir claves en múltiples partes y almacenarlas en varios dispositivos, utilizando técnicas criptográficas para generar firmas, sin necesidad de combinar directamente estas partes de clave.
EIP-7702 es una propuesta que se planea introducir en la próxima bifurcación dura. EIP-7702 es el resultado de una creciente conciencia sobre la conveniencia de proporcionar abstracción de cuentas para beneficiar a todos los usuarios (, incluidos los usuarios de EOA ), y tiene como objetivo mejorar la experiencia de todos los usuarios a corto plazo y evitar la división en dos ecosistemas.
Este trabajo comenzó con EIP-3074 y finalmente se convirtió en EIP-7702. EIP-7702 ofrece la "funcionalidad conveniente" de la abstracción de cuentas a todos los usuarios, incluidos los EOA( de hoy, es decir, cuentas controladas por firmas ECDSA).
Aunque algunos desafíos (, especialmente el desafío de "conveniencia" ), pueden ser resueltos mediante tecnologías progresivas como el cálculo multiparte o el EIP-7702, el principal objetivo de seguridad de la propuesta de abstracción de cuentas inicialmente presentada solo puede lograrse retrocediendo y resolviendo el problema original: permitir que el código de contrato inteligente controle la validación de transacciones. La razón por la cual esto aún no se ha logrado radica en la implementación segura, lo cual es un desafío.
¿Qué es y cómo funciona?
El núcleo de la abstracción de cuentas es simple: permite que los contratos inteligentes inicien transacciones, y no solo EOA. Toda la complejidad proviene de implementar esto de una manera que sea amigable para el mantenimiento de redes descentralizadas y prevenir ataques de denegación de servicio.
Un desafío clave típico es el problema de múltiples fallos:
Si hay 1000 funciones de verificación de cuentas que dependen de un único valor S, y el valor S actual hace que todas las transacciones en el pool de memoria sean válidas, entonces una única transacción que invierta el valor de S podría hacer que todas las otras transacciones en el pool de memoria sean inválidas. Esto permite que un atacante envíe transacciones basura al pool de memoria a un costo muy bajo, bloqueando así los recursos de los nodos de la red.
Tras años de esfuerzo, con el objetivo de expandir las funcionalidades mientras se limita el riesgo de denegación de servicio (DoS), finalmente se llegó a una solución para implementar "abstracción ideal de cuentas": ERC-4337.
El funcionamiento de ERC-4337 divide el procesamiento de las operaciones del usuario en dos fases: verificación y ejecución. Todas las verificaciones se procesan primero, y todas las ejecuciones se procesan después. En el pool de memoria, solo se aceptarán las operaciones del usuario cuya fase de verificación solo involucre su propia cuenta y no lea variables de entorno. Esto puede prevenir ataques de fallos múltiples. Además, se imponen estrictos límites de gas en el paso de verificación.
ERC-4337 fue diseñado como un estándar de protocolo adicional (ERC), porque en ese momento los desarrolladores de clientes de Ethereum se centraban en la fusión (Merge), sin energía adicional para manejar otras funciones. Por eso, ERC-4337 utiliza un objeto llamado operación de usuario, en lugar de transacciones convencionales. Sin embargo, recientemente nos hemos dado cuenta de la necesidad de escribir al menos parte de su contenido en el protocolo.
Las dos razones clave son las siguientes:
Además, ERC-4337 también ha ampliado dos funciones:
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
)# Enlace de investigación existente
)# El trabajo restante y las compensaciones
Actualmente, lo que se necesita resolver principalmente es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas que ha ganado popularidad recientemente es el EIP-7701, que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una sección de código separada para la verificación; si la cuenta establece esta sección de código, se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.
El encanto de este método radica en que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas locales:
Si comenzamos estableciendo límites estrictos sobre la complejidad del código ejecutable durante el período de verificación---no se permite el acceso al estado externo, e incluso el límite de gas establecido inicialmente es tan bajo que es ineficaz para aplicaciones de resistencia cuántica o protección de la privacidad---entonces la seguridad de este enfoque es muy clara: simplemente reemplazar la verificación ECDSA por la ejecución de código EVM que requiere un tiempo similar.
Sin embargo, con el tiempo, necesitamos flexibilizar estos límites, ya que permitir que las aplicaciones de protección de la privacidad funcionen sin intermediarios, así como la resistencia cuántica, son muy importantes. Para ello, necesitamos encontrar formas más flexibles de abordar el riesgo de denegación de servicio ###DoS(, sin requerir que los pasos de verificación sean extremadamente simplistas.
La principal consideración parece ser "escribir rápidamente una solución que satisfaga a menos personas" frente a "esperar más tiempo para posiblemente obtener una solución más ideal", siendo el enfoque ideal posiblemente algún tipo de método híbrido. Un método híbrido podría ser escribir más rápidamente algunos casos de uso y dejar más tiempo para explorar otros casos de uso. Otro enfoque sería desplegar primero una versión más ambiciosa de abstracción de cuentas en L2. Sin embargo, el desafío que enfrenta esto es que el equipo de L2 necesita tener plena confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para asegurar que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.
Otra aplicación que aún necesitamos considerar claramente son las cuentas de almacenamiento de claves, que almacenan el estado relacionado con la cuenta en L1 o L2 dedicado, pero pueden estar en L1 y en cualquier lugar.