Como plataforma de cadena de bloques abierta y programable, Ethereum no solo es la infraestructura de la moneda digital, sino que también proporciona a los desarrolladores un entorno para crear aplicaciones descentralizadas (DAPP) y contratos inteligentes. Debido a su flexibilidad y escalabilidad, Ethereum se ha convertido en un actor clave en el ecosistema de las criptomonedas y ha atraído a desarrolladores y usuarios de todo el mundo.
En el contenido del último número de Cregis Research, discutimos el valor de la abstracción de cuentas (AA), por lo que ampliamos un tema complicado: en junio, V God, el fundador de Ethereum, señaló en su blog que Ethereum actualmente se enfrenta a algunos desafíos y problemas importantes, estos problemas deben resolverse para promover un mayor desarrollo de Ethereum, de lo contrario, Ethereum fallará, por lo que las tres direcciones de transformación son: billetera de contrato inteligente, protección de la privacidad y expansión de Capa 2. Después de una transformación exitosa, Ethereum mejorará en términos de rendimiento, experiencia del usuario y protección de la privacidad.
Por supuesto, estos cambios también traen nuevos desafíos. Los problemas y la importancia de las billeteras de contrato inteligente (CA) se analizaron claramente en el número anterior. Cregis Research resumió algunas de las preguntas restantes y seleccionó algunos puntos clave que están estrechamente relacionados con su experiencia diaria y revisó el punto de vista de Dios hace medio mes.
Nuevos problemas provocados por las tres transformaciones de Ethereum
2. ¿Por qué debe cambiar Ethereum?
La razón principal por la que Ethereum necesita cambiar se deriva de los desafíos de escalabilidad, seguridad y protección de la privacidad.
En primer lugar, revisemos la discusión en el último número de Cregis Research: Cregis Research: The Archaeology of Ethereum Account Structure and the Value of Account Abstraction, que menciona: Ethereum que se ejecuta en un entorno descentralizado aún enfrenta el mayor punto débil: lineal Entorno Es imposible realizar transacciones de alta simultaneidad y compilación de código complejo, lo cual es un desafío de escalabilidad.
Debido a la capacidad limitada actual de procesamiento de transacciones de Ethereum, los costos de transacción pueden volverse altos cuando aumenta el tráfico de la red. Este alto costo de transacción dificulta la popularización de Ethereum en el mercado principal, por lo que Ethereum necesita aumentar su capacidad de procesamiento y reducir los costos de transacción a través de la expansión L2, como acumulaciones.
En segundo lugar, la seguridad de la billetera también es un tema importante. Las billeteras EOA (representadas por varias billeteras enchufables) que generan pares de claves públicas y privadas simplemente a través de frases iniciales están siendo robadas en un flujo interminable. piratas informáticos, los usuarios individuales tienen demandas cada vez más intensas de seguridad de los activos y, al mismo tiempo, no están dispuestos a sacrificar la experiencia del usuario (los usuarios de nivel empresarial elegirán una solución MPC totalmente autohospedada para la seguridad de los activos y están dispuestos a sacrificar la conveniencia de -interacción en cadena), lo que requiere que Ethereum cambie la seguridad de la billetera y promueva las billeteras de contrato inteligente. Los últimos estándares de seguridad de la industria (como EIP-4337) brindan mayor seguridad y comodidad para los usuarios individuales.
Finalmente, la protección de la privacidad es otro desafío clave. Todas las transacciones en Ethereum L1 son públicas porque EOA está vinculada a los activos; ya sean usuarios individuales ordinarios, ballenas gigantes o instituciones corporativas, actualmente pueden sufrir la dificultad de marcar y rastrear las direcciones de los activos. Por lo tanto, Ethereum debe mejorarse aún más para implementar cálculos de privacidad no maliciosos para garantizar que no solo los activos en la cadena, sino también la información DID, como las identidades y los sistemas de crédito en la cadena, puedan protegerse en el futuro; El mecanismo de afrontamiento puede garantizar que los perpetradores no pueden escapar del seguimiento y cobrar sin problemas.
Tres, las 3 preguntas más importantes (comentarios resumidos y agregados por Cregis Research)
Cómo administran los usuarios varias direcciones de billetera
Frente a la Web 3.0, la Web 2.0 tiene la misma ventaja que aún mantiene: los usuarios pueden utilizar una característica social (dirección de correo electrónico, número de teléfono móvil, etc.) para crear diferentes cuentas de aplicaciones, aunque en el mundo de la Web 3.0, las direcciones públicas en cadena con Se puede usar el mismo mecanismo de consenso (por ejemplo: BSC, ERC-20, TRC-20), pero con la llegada del plan de expansión L 2, los usuarios tendrán múltiples direcciones L 2 completamente diferentes y diferentes capas 1 y 2. las redes pueden usar diferentes lenguajes de programación y componentes intermedios, lo que lleva a problemas en la reserva de direcciones; y antes del entorno puente multicadena representado por Polkadot o el entorno L2 multicadena de propósito general mencionado en la visión de futuro de Cregis, los usuarios también pueden necesitar gestionar varias Direcciones de cadenas heterogéneas, lo que aumenta la complejidad de la gestión de direcciones.
Finalmente, la propuesta de dirección sigilosa para la protección de la privacidad, si se usa ampliamente, permitirá a los usuarios tener más direcciones para mejorar su protección de la privacidad. Por lo tanto, se vuelve más difícil reservar una dirección.
¿Cómo realizan los usuarios el pago invisible? (especialmente en un entorno de varias direcciones)
Suponiendo que L2 en el ecosistema Ethereum se desarrolle como se espera en el futuro, incluso si la mayoría de los activos nativos son tokens ERC-20, los usuarios pueden tener varias direcciones L2 y elegir la dirección correcta para enviar activos o pagar se vuelve más complicado. Tradicionalmente, los usuarios solo necesitaban conocer la dirección de la otra parte para enviar un pago, pero ahora necesitan conocer las redes de Capa 2 y las direcciones correspondientes aceptadas por la otra parte, y requieren pasos adicionales para garantizar que los fondos se envíen al destino correcto.
Problema de pago sigiloso de múltiples cuentas en el entorno L 2
Aunque la cuenta de contrato (CA) construida mediante el uso de contratos inteligentes puede resolver fácilmente el problema de direccionamiento, no puede proporcionar directamente la función de protección de la privacidad.
Vitalik propuso una solución de protección de la privacidad en los primeros días de Ethereum: dirección sigilosa. Las direcciones sigilosas pueden ayudarlo a mantener la privacidad cuando realiza transacciones de moneda digital sin ser rastreado por otros. A continuación, Cregis compartirá algunos pasos para resolver problemas de privacidad:
(Flujo de trabajo completo de la dirección sigilosa)
Una dirección sigilosa es una dirección que puede ser generada por el remitente o el beneficiario, pero solo controlada por el beneficiario. Este tipo de dirección puede mejorar la privacidad de Ethereum en varios escenarios. En este modo, Bob (el beneficiario) genera una clave de consumo y utiliza esta clave para generar una metadirección invisible: B, h = hash(x). Pasa esta metadirección a Alice (la pagadora). Alice puede realizar un cálculo en esta metadirección, generando la dirección sigilosa que pertenece a Alice para Bob: b-1. Luego puede enviar los activos que desee a esta dirección y Bob tendrá control total sobre ellos.
El proceso de generación de la dirección sigilosa necesita operar la función de curva elíptica: Bob genera una clave m y calcula M = G * m, donde G es un punto público de generación de la curva elíptica. Alice genera una clave temporal r y publica la clave pública temporal R = G * r. Alice puede calcular un secreto compartido S = M * r, y Bob puede calcular el mismo secreto compartido S = m * R.
Después de que se genera la dirección sigilosa de Bob: b-1, cuando es necesario comerciar con Alice, Alice genera un valor: c, y publica un dato cifrado de c que solo Bob puede descifrar; cuando se ejecuta la transacción, se verifica mediante Prueba de conocimiento cero: Bob proporciona El valor x proporcionado por Alice y el valor c proporcionado por Alice pueden hacer k = hash (hash (x), c), y la transacción se completa después de que la verificación sea correcta. Dado que la dirección original de Bob no se expone durante este proceso, y solo se proporciona el valor cifrado x, la prueba de conocimiento cero solo es responsable de verificar el contenido de k y no mostrará la relación entre B y b-1.
¿Cómo protege el producto de cartera los activos y la privacidad del usuario al mismo tiempo?
En un entorno tradicional en cadena, las billeteras se preocupan principalmente por la protección de las claves privadas, pero en un mundo ZKP (Zero-Knowledge Proof), las billeteras necesitan proteger tanto las credenciales de autenticación como los datos del usuario. Un ejemplo es ZKpass, un sistema de identidad basado en ZK-SNARK y MPC, que permite a los usuarios generar pruebas básicas para la verificación de identidad, y al mismo tiempo realiza el proceso de verificación de identidad sin presentar ninguna información real a través de MPC.
Sin embargo, dado que la etiqueta de datos cifrados (fragmento de clave) en sí misma reemplaza la clave privada de la EOA, la custodia de la etiqueta de datos cifrados se vuelve más problemática, ya que los usuarios deben hacer un compromiso entre mantener los datos localmente o confiar en un tercero para mantener una copia cifrada. Al mismo tiempo, las billeteras que admiten la recuperación social deben administrar la recuperación de activos y la recuperación de claves de cifrado para garantizar un equilibrio entre seguridad y usabilidad. Por lo tanto, en el futuro previsible, las estrategias de seguridad de las billeteras de nivel empresarial y las billeteras personales tendrán direcciones completamente diferentes.Tomando las billeteras de nivel empresarial como ejemplo, los usuarios de billeteras de nivel empresarial necesitan el entorno de seguridad más estricto para proteger los fondos. existe una alta probabilidad de abandonar: 1. Monederos de contrato que pueden tener vulnerabilidades humanas; 2. Monederos MPC de custodia mixta con riesgos de terceros, elija monederos MPC privatizados con el mismo nivel de seguridad que los monederos de hardware; En algunos escenarios, porque siempre desea para obtener la mejor experiencia de usuario, puede elegir un producto con algunas operaciones centralizadas.
Además, la dirección de la cadena de bloques no cumple con los requisitos de verificación de identidad en la ecología, por lo que las soluciones de ENS (nombre de dominio de la cadena de bloques) y SBT (token de unión del alma) son gradualmente aceptadas por el público, pero aún existen problemas que no han sido resueltos. resuelto: el primero es difícil de resolver el problema de los nombres duplicados provocados por el mundo tradicional. Aunque el segundo no tiene el problema de los nombres duplicados, no hay suficientes aplicaciones ecológicas para utilizar completamente las funciones DID que lleva, y incluso se puede decir que los escenarios de aplicación actuales son muy delgados.
4. Resumen
Creo que todos ya han entendido que la billetera es solo una parte importante del tema [Transformación de Ethereum] que ha causado furor en el círculo monetario mundial durante casi 3 meses. La ambición de God of V no es solo realizar la ambición de "Ethereum complementa los defectos de Bitcoin", sino que también espera que Ethereum realmente pueda crear un mundo en el que todos puedan ingresar, que esté altamente conectado con el mundo real y retenga el concepto. de descentralización.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Observación de Cregis Research: Nuevos problemas causados por tres transformaciones de Ethereum
I. Introducción
En el contenido del último número de Cregis Research, discutimos el valor de la abstracción de cuentas (AA), por lo que ampliamos un tema complicado: en junio, V God, el fundador de Ethereum, señaló en su blog que Ethereum actualmente se enfrenta a algunos desafíos y problemas importantes, estos problemas deben resolverse para promover un mayor desarrollo de Ethereum, de lo contrario, Ethereum fallará, por lo que las tres direcciones de transformación son: billetera de contrato inteligente, protección de la privacidad y expansión de Capa 2. Después de una transformación exitosa, Ethereum mejorará en términos de rendimiento, experiencia del usuario y protección de la privacidad.
Por supuesto, estos cambios también traen nuevos desafíos. Los problemas y la importancia de las billeteras de contrato inteligente (CA) se analizaron claramente en el número anterior. Cregis Research resumió algunas de las preguntas restantes y seleccionó algunos puntos clave que están estrechamente relacionados con su experiencia diaria y revisó el punto de vista de Dios hace medio mes.
Nuevos problemas provocados por las tres transformaciones de Ethereum
2. ¿Por qué debe cambiar Ethereum?
La razón principal por la que Ethereum necesita cambiar se deriva de los desafíos de escalabilidad, seguridad y protección de la privacidad.
En primer lugar, revisemos la discusión en el último número de Cregis Research: Cregis Research: The Archaeology of Ethereum Account Structure and the Value of Account Abstraction, que menciona: Ethereum que se ejecuta en un entorno descentralizado aún enfrenta el mayor punto débil: lineal Entorno Es imposible realizar transacciones de alta simultaneidad y compilación de código complejo, lo cual es un desafío de escalabilidad.
Debido a la capacidad limitada actual de procesamiento de transacciones de Ethereum, los costos de transacción pueden volverse altos cuando aumenta el tráfico de la red. Este alto costo de transacción dificulta la popularización de Ethereum en el mercado principal, por lo que Ethereum necesita aumentar su capacidad de procesamiento y reducir los costos de transacción a través de la expansión L2, como acumulaciones.
En segundo lugar, la seguridad de la billetera también es un tema importante. Las billeteras EOA (representadas por varias billeteras enchufables) que generan pares de claves públicas y privadas simplemente a través de frases iniciales están siendo robadas en un flujo interminable. piratas informáticos, los usuarios individuales tienen demandas cada vez más intensas de seguridad de los activos y, al mismo tiempo, no están dispuestos a sacrificar la experiencia del usuario (los usuarios de nivel empresarial elegirán una solución MPC totalmente autohospedada para la seguridad de los activos y están dispuestos a sacrificar la conveniencia de -interacción en cadena), lo que requiere que Ethereum cambie la seguridad de la billetera y promueva las billeteras de contrato inteligente. Los últimos estándares de seguridad de la industria (como EIP-4337) brindan mayor seguridad y comodidad para los usuarios individuales.
Finalmente, la protección de la privacidad es otro desafío clave. Todas las transacciones en Ethereum L1 son públicas porque EOA está vinculada a los activos; ya sean usuarios individuales ordinarios, ballenas gigantes o instituciones corporativas, actualmente pueden sufrir la dificultad de marcar y rastrear las direcciones de los activos. Por lo tanto, Ethereum debe mejorarse aún más para implementar cálculos de privacidad no maliciosos para garantizar que no solo los activos en la cadena, sino también la información DID, como las identidades y los sistemas de crédito en la cadena, puedan protegerse en el futuro; El mecanismo de afrontamiento puede garantizar que los perpetradores no pueden escapar del seguimiento y cobrar sin problemas.
Tres, las 3 preguntas más importantes (comentarios resumidos y agregados por Cregis Research)
Cómo administran los usuarios varias direcciones de billetera
Frente a la Web 3.0, la Web 2.0 tiene la misma ventaja que aún mantiene: los usuarios pueden utilizar una característica social (dirección de correo electrónico, número de teléfono móvil, etc.) para crear diferentes cuentas de aplicaciones, aunque en el mundo de la Web 3.0, las direcciones públicas en cadena con Se puede usar el mismo mecanismo de consenso (por ejemplo: BSC, ERC-20, TRC-20), pero con la llegada del plan de expansión L 2, los usuarios tendrán múltiples direcciones L 2 completamente diferentes y diferentes capas 1 y 2. las redes pueden usar diferentes lenguajes de programación y componentes intermedios, lo que lleva a problemas en la reserva de direcciones; y antes del entorno puente multicadena representado por Polkadot o el entorno L2 multicadena de propósito general mencionado en la visión de futuro de Cregis, los usuarios también pueden necesitar gestionar varias Direcciones de cadenas heterogéneas, lo que aumenta la complejidad de la gestión de direcciones.
Finalmente, la propuesta de dirección sigilosa para la protección de la privacidad, si se usa ampliamente, permitirá a los usuarios tener más direcciones para mejorar su protección de la privacidad. Por lo tanto, se vuelve más difícil reservar una dirección.
¿Cómo realizan los usuarios el pago invisible? (especialmente en un entorno de varias direcciones)
Suponiendo que L2 en el ecosistema Ethereum se desarrolle como se espera en el futuro, incluso si la mayoría de los activos nativos son tokens ERC-20, los usuarios pueden tener varias direcciones L2 y elegir la dirección correcta para enviar activos o pagar se vuelve más complicado. Tradicionalmente, los usuarios solo necesitaban conocer la dirección de la otra parte para enviar un pago, pero ahora necesitan conocer las redes de Capa 2 y las direcciones correspondientes aceptadas por la otra parte, y requieren pasos adicionales para garantizar que los fondos se envíen al destino correcto.
Problema de pago sigiloso de múltiples cuentas en el entorno L 2
Aunque la cuenta de contrato (CA) construida mediante el uso de contratos inteligentes puede resolver fácilmente el problema de direccionamiento, no puede proporcionar directamente la función de protección de la privacidad.
Vitalik propuso una solución de protección de la privacidad en los primeros días de Ethereum: dirección sigilosa. Las direcciones sigilosas pueden ayudarlo a mantener la privacidad cuando realiza transacciones de moneda digital sin ser rastreado por otros. A continuación, Cregis compartirá algunos pasos para resolver problemas de privacidad:
(Flujo de trabajo completo de la dirección sigilosa)
Una dirección sigilosa es una dirección que puede ser generada por el remitente o el beneficiario, pero solo controlada por el beneficiario. Este tipo de dirección puede mejorar la privacidad de Ethereum en varios escenarios. En este modo, Bob (el beneficiario) genera una clave de consumo y utiliza esta clave para generar una metadirección invisible: B, h = hash(x). Pasa esta metadirección a Alice (la pagadora). Alice puede realizar un cálculo en esta metadirección, generando la dirección sigilosa que pertenece a Alice para Bob: b-1. Luego puede enviar los activos que desee a esta dirección y Bob tendrá control total sobre ellos.
El proceso de generación de la dirección sigilosa necesita operar la función de curva elíptica: Bob genera una clave m y calcula M = G * m, donde G es un punto público de generación de la curva elíptica. Alice genera una clave temporal r y publica la clave pública temporal R = G * r. Alice puede calcular un secreto compartido S = M * r, y Bob puede calcular el mismo secreto compartido S = m * R.
Después de que se genera la dirección sigilosa de Bob: b-1, cuando es necesario comerciar con Alice, Alice genera un valor: c, y publica un dato cifrado de c que solo Bob puede descifrar; cuando se ejecuta la transacción, se verifica mediante Prueba de conocimiento cero: Bob proporciona El valor x proporcionado por Alice y el valor c proporcionado por Alice pueden hacer k = hash (hash (x), c), y la transacción se completa después de que la verificación sea correcta. Dado que la dirección original de Bob no se expone durante este proceso, y solo se proporciona el valor cifrado x, la prueba de conocimiento cero solo es responsable de verificar el contenido de k y no mostrará la relación entre B y b-1.
¿Cómo protege el producto de cartera los activos y la privacidad del usuario al mismo tiempo?
En un entorno tradicional en cadena, las billeteras se preocupan principalmente por la protección de las claves privadas, pero en un mundo ZKP (Zero-Knowledge Proof), las billeteras necesitan proteger tanto las credenciales de autenticación como los datos del usuario. Un ejemplo es ZKpass, un sistema de identidad basado en ZK-SNARK y MPC, que permite a los usuarios generar pruebas básicas para la verificación de identidad, y al mismo tiempo realiza el proceso de verificación de identidad sin presentar ninguna información real a través de MPC.
Sin embargo, dado que la etiqueta de datos cifrados (fragmento de clave) en sí misma reemplaza la clave privada de la EOA, la custodia de la etiqueta de datos cifrados se vuelve más problemática, ya que los usuarios deben hacer un compromiso entre mantener los datos localmente o confiar en un tercero para mantener una copia cifrada. Al mismo tiempo, las billeteras que admiten la recuperación social deben administrar la recuperación de activos y la recuperación de claves de cifrado para garantizar un equilibrio entre seguridad y usabilidad. Por lo tanto, en el futuro previsible, las estrategias de seguridad de las billeteras de nivel empresarial y las billeteras personales tendrán direcciones completamente diferentes.Tomando las billeteras de nivel empresarial como ejemplo, los usuarios de billeteras de nivel empresarial necesitan el entorno de seguridad más estricto para proteger los fondos. existe una alta probabilidad de abandonar: 1. Monederos de contrato que pueden tener vulnerabilidades humanas; 2. Monederos MPC de custodia mixta con riesgos de terceros, elija monederos MPC privatizados con el mismo nivel de seguridad que los monederos de hardware; En algunos escenarios, porque siempre desea para obtener la mejor experiencia de usuario, puede elegir un producto con algunas operaciones centralizadas.
Además, la dirección de la cadena de bloques no cumple con los requisitos de verificación de identidad en la ecología, por lo que las soluciones de ENS (nombre de dominio de la cadena de bloques) y SBT (token de unión del alma) son gradualmente aceptadas por el público, pero aún existen problemas que no han sido resueltos. resuelto: el primero es difícil de resolver el problema de los nombres duplicados provocados por el mundo tradicional. Aunque el segundo no tiene el problema de los nombres duplicados, no hay suficientes aplicaciones ecológicas para utilizar completamente las funciones DID que lleva, y incluso se puede decir que los escenarios de aplicación actuales son muy delgados.
4. Resumen
Creo que todos ya han entendido que la billetera es solo una parte importante del tema [Transformación de Ethereum] que ha causado furor en el círculo monetario mundial durante casi 3 meses. La ambición de God of V no es solo realizar la ambición de "Ethereum complementa los defectos de Bitcoin", sino que también espera que Ethereum realmente pueda crear un mundo en el que todos puedan ingresar, que esté altamente conectado con el mundo real y retenga el concepto. de descentralización.