TL;DR

La clave privada es el núcleo que nos permite firmar transacciones en Ethereum, pero administrarla ha sido una pesadilla, incluso en la forma legible de "frases semilla". Sin embargo, nuestro objetivo nunca fue convertir la cadena de bloques en un juego sofisticado.

Autenticar usuarios autorizados es crucial para transacciones seguras. Con la evolución de la seguridad en internet y la experiencia de usuario, hemos pasado de la autenticación por contraseña a la biometría como reconocimiento facial y huellas dactilares. WebAuthn es un desarrollo clave en esta progresión. Este artículo analiza de cerca tres términos:

WebAuthn: Un estándar de autenticación web que utiliza credenciales basadas en clave pública, a menudo creadas por autenticadores externos. Elimina la necesidad de contraseñas y permite una autenticación segura del usuario.

Enclave Seguro: Un área segura basada en hardware dentro de dispositivos informáticos, el Enclave Seguro está diseñado para proteger datos sensibles. Se encuentran versiones de un Enclave Seguro en dispositivos iOS, Android y Windows. Puede servir como un autenticador seguro mediante la implementación de WebAuthn, pero la clave privada, vinculada al ES, a menudo presenta desafíos entre dispositivos.

Passkey: Una implementación de WebAuthn a nivel del sistema operativo, personalizada por diversos proveedores de dispositivos y sistemas. Por ejemplo, Passkey de Apple utiliza la clave almacenada en iCloud Keychain para la sincronización entre dispositivos. Sin embargo, este enfoque suele estar bloqueado para plataformas o sistemas específicos.

Como se describe anteriormente, las implementaciones de webAuthn se alinean con nuestro objetivo para los usuarios diarios de blockchain, lograr una seguridad antiphishing de alto nivel y una experiencia amigable. Aquí está la idea de fusionarlas en blockchain:

Capa clave: Los usuarios se autentican utilizando métodos biométricos perfectos como reconocimiento facial o huella dactilar. En el fondo, es el procesador de seguridad basado en hardware como Secure Enclave o los servicios en la nube como iCloud y Google Cloud los que manejan la gestión de claves. Más adelante abordaré los problemas de interconexión entre dispositivos y plataformas.

Capa de cuenta: Una Cuenta de Contrato Inteligente (CCI) ofrece la capacidad de asignar firmantes arbitrarios (por ejemplo, SE y Passkey) y mecanismos de umbral. Además, su diseño modular mejora la flexibilidad y la capacidad de actualización. Por ejemplo, una CCI puede adaptar sus requisitos de firma dinámicamente en función de factores como la cantidad de la transacción, el tiempo o la dirección IP. Por otro lado, una Cuenta Externa de Propiedad Tradicional (EOA) puede ser ampliada con servicios de MPC, su combinación ofrece una mejor interoperabilidad y rentabilidad en comparación con CCI, aunque carece de funcionalidades avanzadas que las CCI proporcionan, especialmente para la rotación de claves.

Capa de firma: Ethereum admite nativamente la curva k1, pero la verificación de firma de WebAuthn conlleva costos más altos, ya que utiliza la curva r1 para la generación de claves. Por lo tanto, algunas soluciones de Capa 2 como zkSync, planean precompilaciones nativas de la curva r1 de EIP-7212. Además, existen servicios de terceros, verificadores de Solidity, verificadores de conocimiento cero (ZK) y sistemas de gestión de claves distribuidas para facilitar la firma de la curva r1 de manera más rentable.

Descargo de responsabilidad:

El avance tecnológico no garantiza el éxito en el mercado; No todos los dispositivos y plataformas han adoptado Passkey; Usar SCA puede ser más caro que EOA; La solución propuesta evoluciona con el progreso tecnológico.

¿La experiencia de usuario en Cripto es mala? ¡La gestión de claves es mala!

En el ámbito de la cadena de bloques, el control real de los activos de la cadena de bloques no está en manos del usuario o del proveedor de monederos, sino que radica en la clave privada. Esta clave es la más importante para todo el proceso de ejecución de una transacción en Ethereum. Para entender esto mejor, tomemos EOA como ejemplo:

Generación de claves: Se selecciona un número aleatorio de la curva elíptica secp256k1 como la clave privada. Luego, esta clave se multiplica por un punto predefinido en la curva para generar la clave pública. La dirección de Ethereum se deriva de los últimos 20 bytes de la clave pública hasheada. La 'frase semilla' suele introducirse para hacer una copia de seguridad legible para los humanos, lo que permite la derivación determinista de claves privadas y públicas.

Firmar Transacciones: Una transacción, que contiene detalles como nonce (un número secuencial), cantidad, precio del gas y dirección del destinatario, se firma usando la clave privada. Este proceso, que implica el ECDSA, un algoritmo de firma digital que utiliza criptografía de curva elíptica y adopta secp256k1 como la curva, genera una firma que consiste en valores (r, s, v). La firma y la transacción original se transmiten luego en la red.

Verificación de transacciones: Una vez que una transacción llega a los nodos de Ethereum, se somete a un proceso de validación en la mempool del nodo. Para verificar al firmante, los nodos utilizan la firma y la transacción hash para derivar la clave pública del remitente y confirmar la autenticidad de la transacción mediante la coincidencia de la dirección derivada con la del remitente.

Como se describió anteriormente, la clave privada es una entidad esencial en la cadena. Originalmente, las cuentas de Ethereum, conocidas como Cuentas Propias Externas (EOAs), dependían únicamente de una sola clave privada, lo que representaba riesgos significativos, ya que perder la clave significaba perder acceso a la cuenta.

Muchos pueden pensar que la Abstracción de Cuenta (AA) es la solución para todo lo relacionado con la mala experiencia del usuario, lo cual diré que no es exactamente así. AA se trata de cambiar las reglas de validez para que sean programables, y la programabilidad de la Cuenta de Contrato Inteligente (SCAs) lo hace posible. AA es poderoso, permite enviar múltiples transacciones en paralelo (nonce abstracto), patrocinio de gas y pagar gas en ERC20 (gas abstracto), y más relevante para el tema de este artículo, romper la validación de firma fija (firma abstracta de ECDSA). En lugar de EOA, las SCAs pueden asignar firmantes arbitrarios y mecanismos de firma como la firma múltiple (multifirmas) o claves con alcance (claves de sesión). Sin embargo, a pesar de la flexibilidad y el avance en la capacidad de actualización de AA, la dependencia fundamental de la(s) clave(s) para la firma de transacciones permanece inalterada.

Incluso cuando se convierte en una frase semilla de 12 palabras, la gestión de una clave privada sigue siendo un reto, ya que plantea riesgos de pérdida o ataques de phishing. Los usuarios deben navegar entre capas complejas de soluciones descentralizadas o la cálida adopción del servicio centralizado, ninguna de ellas es ideal.

¿Por qué la experiencia en cripto es tan mala? Gran parte de ello se debe a que la gestión de claves es deficiente. Siempre requiere compromisos en la experiencia, seguridad y descentralización. Este artículo explora posibles soluciones óptimas para gestionar la clave.

Capas de gestión de claves

Nunca habrá una solución única, la mejor manera de preservar la clave se adapta a escenarios de usuario específicos, influenciada por factores como el tipo de usuario (institucional o individual), monto de capital, frecuencia de transacciones y tipos de interacción.

Para aclarar de antemano, evito usar los populares métodos de 'auto custodia, semi custodia y custodia completa' para catalogar. En mi opinión, la verdadera auto custodia implica firmar una transacción de forma independiente, sin depender de otra parte, incluso si la solución no es custodial en el sentido tradicional (como estar almacenada en los TEE de nodos descentralizados). Clasificar las soluciones simplemente como 'buenas' o 'malas' basándose en el tipo de custodia es demasiado simplista y no tiene en cuenta su idoneidad variada. Para una evaluación más matizada de los métodos de gestión de claves, sugiero analizarlos a través de tres capas distintas:

Responsabilidad

Si dividir la responsabilidad de gestionar una llave entre diferentes partes.

Dado que las personas a menudo enfrentan desafíos para administrar la clave, distribuir la responsabilidad de salvaguardarla surge como una estrategia natural de mitigación de riesgos. Esta categoría incluye métodos como usar múltiples claves para firmar de manera colaborativa, como se ve en los sistemas de Firma Múltiple (Multi-sig), y dividir la clave privada en partes a través de un Esquema de Compartición Secreta (SSS) o una Computación de Partes Múltiples (MPC).

Multi-firma: Requiere múltiples claves privadas completas para generar firmas de transacción. Este método requiere comunicación en cadena sobre los diferentes firmantes, lo que conlleva mayores tarifas de transacción e impacta la privacidad porque el número de firmantes es visible en cadena.

SSS: se genera una clave privada en una sola ubicación, y un distribuidor reparte fragmentos de esta clave a diferentes partes. Todas las partes deben reconstruir la clave privada completa para firmar una transacción. Sin embargo, esta reconstrucción temporal puede introducir vulnerabilidades.

MPC-TSS(Threshold Signature Scheme): como una implementación de MPC, un enfoque criptográfico que permite a varias partes realizar cálculos manteniendo sus entradas de forma conjunta. Cada parte crea independientemente una parte de la clave secreta, y las transacciones se firman sin que estas partes necesiten reunirse físicamente. Introduce tarifas más bajas porque está fuera de la cadena, y no hay riesgo de un solo punto de fallo como SSS.

Almacenamiento

Almacenar la clave o acciones, afectadas por factores de seguridad, accesibilidad, costo y descentralización.

Servicios de nube centralizados como AWS, iCloud y otros servidores. Son convenientes para transacciones frecuentes, pero más vulnerables a la censura.

Almacenamiento descentralizado como IPFS y Filecoin.

Ordenador/móvil local: Las claves se almacenan localmente dentro del almacenamiento seguro del navegador.

Billeteras de papel: Impresión física de claves privadas o códigos QR.

Entorno de Ejecución Confiable (TEE): TEE proporciona un área segura dentro del procesador principal para ejecutar o almacenar datos sensibles, aislados del sistema operativo principal.

Enclave Segura: La Enclave Segura en dispositivos modernos está aislada del procesador principal para proporcionar una capa adicional de seguridad y está diseñada para mantener seguros los datos sensibles del usuario incluso cuando el núcleo del Procesador de Aplicaciones se ve comprometido.

Monederos de hardware: Dispositivos físicos como Ledger y Trezor, específicamente diseñados para almacenar de forma segura claves privadas.

Módulo de seguridad de hardware (HSM): Los HSM son dispositivos de hardware especializados diseñados para la gestión segura de claves y operaciones criptográficas. Normalmente se utilizan en entornos empresariales y ofrecen características de seguridad de alto nivel.

Acceso

Cómo verificar la identidad del usuario para acceder a la clave almacenada

La autenticación está involucrada en acceder a la clave almacenada. Se trata de validar que la persona que intenta acceder esté realmente autorizada para hacerlo. Mirando hacia atrás en la historia, podemos categorizar la historia de esta manera:

Algo que sabes: contraseñas, PIN, respuestas a preguntas de seguridad o patrones específicos.

Algo que tienes: Incluye tarjetas inteligentes, tokens de hardware (contraseñas de un solo uso basadas en el tiempo) o factores digitales como verificaciones de cuentas sociales y códigos SMS enviados a un teléfono.

Alguien que eres: Involucra características físicas únicas del usuario, como huellas dactilares, reconocimiento facial (como Face ID de Apple o Windows Hello), reconocimiento de voz, o escaneos de iris/retina.

Sobre estas, 2FA y MFA son métodos que combinan dos o más factores, como la notificación push combinada con SMS, para agregar más capas de seguridad a las cuentas de usuario.

Análisis de Jugadores Existentes

MetaMask permite a los usuarios usar una contraseña para acceder a la clave almacenada en el almacenamiento local del navegador del usuario.

Trust Wallet permite a los usuarios utilizar una contraseña o faceID para acceder a la clave almacenada en el almacenamiento del navegador local del usuario, el usuario también puede elegir un servicio en la nube para hacer una copia de seguridad de la clave privada.

Privy permite a los usuarios utilizar varios métodos de inicio de sesión social como correo electrónico, usando SSS para dividir tres partes:

Compartir dispositivo: Navegador-iFrame, móvil- enclave seguro.

Auth share: Almacenado por privado, enlace a identificación privada).

Compartir de recuperación: Contraseña de usuario o cifrada por Privy almacenada en el módulo de seguridad de hardware (HSM).

Particle permite a los usuarios utilizar el inicio de sesión social, utilizando MPC-TSS que tiene dos partes:

Compartir dispositivo: navegador-iFrame

Compartir clave del servidor: servidor de Particle

Nueva Solución

Capa clave: WebAuthn, Secure Enclave y Passkey

Las soluciones existentes anteriores han sido fundamentales para presentar a los usuarios a web3. Sin embargo, a menudo vienen con desafíos: las contraseñas pueden olvidarse o ser objeto de ataques de phishing, e incluso el 2FA, aunque más seguro, puede ser engorroso con sus múltiples pasos. Además, no todos se sienten cómodos confiando en un tercero con la gestión de claves, los usuarios todavía dependen de la disponibilidad y la vivacidad de su sistema, mientras que algunos servicios aseguran que no pueden acceder a la clave.

Esto nos lleva a reflexionar si existe una solución más efectiva, una que ofrezca la solución más cercana a una experiencia de usuario sin confianza, alta seguridad y sin problemas. Esta búsqueda nos lleva a los métodos óptimos de web2. Varios términos están estrechamente relacionados con el tema, como describí al principio del artículo, WebAuthn es el estándar de autenticación en sí mismo, mientras que Secure Enclave y Passkey son implementaciones o componentes relacionados con este estándar.

WebAuthn

El estándar WebAuthn normaliza la interfaz de autenticación de usuarios en aplicaciones web. Permite a los usuarios iniciar sesión en cuentas de Internet utilizando autenticadores externos en lugar de una contraseña. Los autenticadores podrían ser Autenticadores Itinerantes (Yubikey, Titan key) o un Autenticador de Plataforma (llavero incorporado en dispositivos Apple), y así sucesivamente.

La Alianza FIDO (Fast IDentity Online) desarrolló inicialmente las tecnologías detrás de WebAuthn. Fue declarada oficialmente como un estándar web por el W3C en marzo de 2019 y, junto con su estandarización, los principales navegadores como Google Chrome, Mozilla Firefox, Microsoft Edge y Apple Safari han adoptado WebAuthn, aumentando significativamente su alcance y usabilidad. Ahora es compatible con muchos dispositivos avanzados.

Beneficios de webAuthn:

Seguridad mejorada: Elimina la dependencia de contraseñas, reduciendo la vulnerabilidad a ataques de phishing, fuerza bruta y de repetición.

Experiencia del usuario mejorada: Ofrece un proceso de inicio de sesión más simple y rápido, a menudo con solo un toque o verificación biométrica.

Protección de la privacidad: No se transmiten secretos compartidos durante la autenticación y los sitios web individuales no reciben ninguna información personal identificable.

Escalabilidad y Estandarización: Como estándar web, WebAuthn garantiza consistencia e interoperabilidad entre diferentes navegadores y plataformas.

WebAuthn vinculado al dispositivo, por ejemplo, Secure Enclave

En casos modernos, podemos usar el procesador de hardware como el autenticador, como Secure Enclave para dispositivos Apple, Trustzone para Android y Strongbox para Google Pixel.

Generación de clave: Utilizando criptografía de clave pública, se genera un par de claves de acuerdo con los estándares de WebAuthn, típicamente utilizando la curva P-256 r1. La clave pública se envía al servicio, mientras que la clave privada NUNCA sale del Enclave Seguro. El usuario nunca maneja la clave en texto plano, lo que dificulta que la clave privada se vea comprometida.

Almacenamiento de claves: la clave privada se almacena de forma segura dentro del Enclave Seguro del dispositivo, un subsistema fortificado segregado del procesador principal. Protege los datos sensibles, asegurando que incluso si el sistema principal se ve comprometido, el material clave crudo permanece inaccesible. La barrera para comprometer el Enclave Seguro es extremadamente alta, y por lo tanto los tipos de datos más sensibles como Apple Pay y los datos de FaceID se almacenan allí. Aquí tienes una explicación detallada de cómo funciona el Enclave Seguro.

Autenticación: los usuarios utilizan su reconocimiento facial o huella dactilar para acceder, el Secure Enclave utiliza la clave privada para firmar un desafío del servicio, y el servicio verifica utilizando la clave pública.

Pros de webAuthn basado en dispositivo:

Seguridad a nivel de hardware: Utilizando Secure Enclave, un administrador de claves basado en hardware aislado para proporcionar una capa adicional de seguridad.

Resistencia al phishing: No involucre la introducción de ninguna información en dispositivos o sitios web potencialmente comprometidos.

Experiencia conveniente: proporcionan una experiencia más amigable para el usuario. Los usuarios ya no necesitan recordar contraseñas complejas para diferentes sitios.

Desventajas de webAuthn basado en dispositivos:

Restricciones del dispositivo: La clave privada no se puede exportar o recuperar si el dispositivo se pierde o se daña, la operación entre dispositivos es imposible.

WebAuthn basado en la nube, Passkey

Abordando el desafío de la funcionalidad entre dispositivos, los gigantes tecnológicos han introducido la implementación webAuthn basada en la nube, Passkey es ampliamente conocido debido a Apple.

Tomemos la Passkey de Apple como ejemplo:

Generación de claves: El dispositivo macOS, iOS o iPadOS del usuario, como autenticador, genera un par de claves pública-privada cuando el usuario crea la cuenta. Luego envía la clave pública al servidor, y la clave privada se almacena en el llavero de iCloud del dispositivo. Los datos del Llavero de iCloud están cifrados con un par de claves vinculadas al hardware, y almacenados en un módulo de seguridad de hardware (HSM). La clave es inaccesible para Apple.

Sincronización entre dispositivos: Este proceso será el mismo que acceder a iCloud. Autentíquese en la cuenta de iCloud, reciba un código SMS e ingrese el código de acceso de uno de los dispositivos.

Pros de webAuthn basado en la nube:

Dispositivo cruzado: Las claves de acceso fueron diseñadas para ser convenientes y accesibles desde todos los dispositivos utilizados de forma regular. Pero actualmente están limitadas a dispositivos Apple, para Android es más desafiante debido a sus diversas versiones y variaciones de hardware.

Resistencia al phishing: Igual que arriba.

Experiencia Conveniente: Igual que arriba.

Contraseñas basadas en la nube contras:

Depender del servicio en la nube: En comparación con webAuthn basado en dispositivos, la clave de paso basada en la nube traslada el nivel de seguridad del hardware de Secure Enclave al llavero de iCloud, algunos pueden argumentar que es custodial para su servicio en la nube. Algunos aspectos clave a considerar incluyen: La cuenta de AppleID del usuario utilizada con iCloud está comprometida; Si bien iCloud Keychain emplea cifrado de extremo a extremo para proteger los datos, errores operativos o vulnerabilidades representan un riesgo.

Restringir a la plataforma: Por ejemplo, usar una clave de acceso basada en iCloud en un dispositivo Android es extremadamente desafiante. Además, a diferencia de los métodos tradicionales, Apple y Google no envían afirmaciones específicas del dispositivo. Esto significa que actualmente es imposible verificar el tipo de dispositivo que generó una clave, lo que plantea preguntas sobre la fiabilidad de la clave y sus metadatos asociados.

Capa de cuenta: SCA y EOA

Hasta ahora, podemos ver que mantener la seguridad a nivel de hardware mientras se aborda la compatibilidad entre dispositivos y plataformas es un desafío. Igualmente crucial es la opción de recuperación social, como agregar múltiples guardianes para una seguridad mejorada. En este contexto, la cadena de bloques puede mostrarnos un camino.

Una brecha notable cuando intentamos implementar web2 webAuthn en web3: Web2 solo requiere demostrar la propiedad, mientras que web3 también requiere autorizar la transacción simultáneamente. Con Passkey, los desarrolladores carecen de control sobre el mensaje de firma, que suele ser genérico, como 'iniciar sesión'. Esto puede llevar a una manipulación potencial del front-end, los usuarios firmando mensajes a ciegas, una preocupación aparentemente menor pero crucial.

Las cuentas de contratos inteligentes (SCA), inherentemente contratos inteligentes por sí mismos, funcionan como entidades en cadena, capaces de asignar firmantes arbitrarios. Esta flexibilidad permite programar varios dispositivos y plataformas, como configurar un teléfono Android, una Macbook y un iPhone, como firmantes. Además, la Cuenta de Contrato Inteligente Modular permite la posibilidad de actualización, reemplazando nuevos firmantes, cambiando el umbral de firma de 2 de 3 a configuraciones aún más intrincadas.

Imagina una billetera que adapta sus requisitos de seguridad en función del contexto: permite la autenticación de un solo firmante cuando el usuario se encuentra en una dirección IP local familiar, pero requiere varios firmantes para transacciones desde direcciones IP desconocidas o por encima de un cierto valor. Con modularidad y programabilidad, nuestra imaginación es el único límite para tales innovaciones. Muchos proveedores de servicios de SCA construyen activamente este espacio, incluidos Safe, Zerodev, Biconomy, Etherspots, Rhinestone, etc. También un reconocimiento a la infraestructura como Stackup, Plimico, Alchemy hacen posible esto.

Por favor, verifica que mi investigación previa brinde un contexto más completo sobre SCA.

Las EOAs pueden lograr la recuperación social y la compatibilidad entre dispositivos/plataformas a través de servicios de MPC. A pesar de que las EOAs tienen signatarios fijos, los proveedores de MPC pueden dividir las claves en partes para una seguridad y flexibilidad mejoradas. Este método carece de las funciones programables y actualizables de SCA, como la recuperación por timelock y la desactivación fácil de claves. Sin embargo, sigue ofreciendo capacidades superiores de interoperabilidad entre cadenas al ser agnóstico de la cadena y actualmente es más rentable que SCA. Proveedores de MPC destacados incluyen Privy, Particle Network, web3Auth, billetera OKX, billetera Binance, etc.

Capa de firma: R1 suppor

Demos un paso atrás para entender el contexto: En Ethereum, las claves privadas son números aleatorios seleccionados de la curva k1, y el proceso de firma también utiliza esta curva.

Sin embargo, los pares de claves generados de acuerdo con los estándares de WebAuthn utilizan la curva r1. Por lo tanto, verificar una firma r1 en Ethereum es aproximadamente tres veces más costoso que una firma k1. Aquí hay algunos enfoques para abordar esto:

Créditos a Dogan, para obtener conocimientos más profundos, por favor revisa su investigación.

Solución de Protocolo:

Solución: EIP7212, Precompilado para soporte de la Curva secp256r1 propuesto por el equipo Clave.

Evaluación: Esta propuesta crea un contrato precompilado que realiza verificaciones de firma en la curva elíptica "secp256r1" mediante los parámetros dados del hash del mensaje, los componentes r y s de la firma, y las coordenadas x e y de la clave pública. De este modo, cualquier cadena EVM -principalmente rollups de Ethereum- podrá integrar fácilmente este contrato precompilado. Hasta ahora, el precompilado del protocolo puede ser la solución más eficiente en gas.

Implementación: zkSync

Servicio de terceros

Solución: Llave en mano

Evaluación: un TEE de Turquía asegura que la clave privada solo sea accesible para el usuario a través de su PassKey y nunca sea accesible para el propio Turnkey, sin embargo, esto aún requiere la vitalidad del servicio.

Implementación: Goldfinch

Soluciones Verificadoras de Solidity:

Solución: Verificador de solidez de FCL, verificador de solidez de FCL con precomputación, P256Verifier de Daimo

Implementación: Clave, Obvious Wallet

Verificador de conocimiento cero (ZK):

Solución: Bonsái Risc0, halo2-ecc de Axiom

Evaluación: Este enfoque aprovecha las pruebas de conocimiento cero para verificar cálculos fuera de la Máquina Virtual Ethereum (EVM), reduciendo los costos computacionales en cadena.

Implementación: Bonfire Wallet(Risc0), Know Nothing Labs(Axiom)

Cada una de estas soluciones ofrece un método diferente para potenciar la verificación de firmas r1 más barata y factible en el ecosistema de Ethereum, y aquí hay una evaluación de Dogan.

Estudio de caso de implementación

*Tenga en cuenta que, a partir de diciembre de 2023, la mayoría de estas soluciones se encuentran en sus primeras etapas y pueden cambiar o mejorar en cualquier momento. Estos ejemplos son solo con fines educativos; siempre consulte sus sitios web oficiales para obtener información precisa.

Clave wallet: (Secure Enclave webAuthn) + (SCA)

Conceptos básicos:

Demo: https://getclave.io/

Cuenta: SCA

Cadena: ZkSync

Proceso de transacción:

Creación de clave: el usuario proporciona autenticación biométrica como huella dactilar o reconocimiento facial, se genera un par de claves dentro del Enclave Seguro, que nunca se revela ni sale al exterior.

Firma de clave: La aplicación toma un mensaje de transacción requerido y reenvía una solicitud de firma al Secure Enclave, el usuario proporciona bio-autenticación para aprobar la firma, y el Secure Enclave firma el mensaje con la clave, y se transmite a los nodos de la cadena de bloques.

Funciones adicionales: La cuenta de contrato inteligente habilita muchas funciones potentes. En primer lugar, el patrocinio del gas. Debido al pagador, otras partes como dApp o anunciantes pueden pagar la tarifa de gas del usuario, lo que hace que el proceso de transacción sea más fluido, y también pueden permitir que los usuarios paguen gas en ERC20 en lugar de Ether o token nativo. Y usando la clave de sesión, el usuario puede realizar transacciones sin firma en un período de tiempo.

Mecanismo de recuperación:

El proceso de recuperación es realizado por el contrato inteligente de Clave en zkSync, el usuario puede cancelar la recuperación durante un bloqueo de tiempo de 48 horas, para prevenir actividades no autorizadas y maliciosas.

Respaldo en la nube: Se creará un EOA cuando el usuario elija el respaldo en la nube, la clave privada del EOA se almacenará en iCloud o Google Drive, el usuario puede usar esta clave privada almacenada en la nube para acceder a su cuenta desde un dispositivo diferente, y los usuarios pueden eliminar o sobrescribir esta sección de respaldo en cualquier momento.

Recuperación social: el usuario puede asignar la dirección de clave de su familia o amigo como respaldo, si M de N guardianes dan confirmación para la recuperación, la recuperación se ejecutará después de 48 horas de bloqueo si no se cancela.

Soul wallet: (Passkey) + (4337 SCA)

Básico:

Demo: https://alpha.soulwallet.io/wallet

Cuenta: ERC4337 SCA

Cadena: Ethereum, Optimism, Arbitrum y pronto todos los EVM de capa2

Proceso de transacción:

Creación de clave: Los usuarios proporcionan autenticación biométrica como huella dactilar o reconocimiento facial, y el sistema operativo genera una Contraseña y la respalda utilizando el servicio en la nube. Puede agregar más de una contraseña en dispositivos y plataformas cruzados.

Agregar guardianes (Opcional): El usuario puede asignar diferentes direcciones de EVM EOA como guardianes y establecer un umbral para la recuperación de la cuenta.

Generación de cuenta: Utilizando implementación contrafáctica, los usuarios no necesitan pagar ninguna tarifa hasta la primera transacción

Mecanismo de recuperación:

Clave: Utilice cualquier clave definida para iniciar sesión en la billetera utilizando un dispositivo arbitrario.

Recuperación de guardianes: Los guardianes asignados pueden rotar la billetera de acuerdo con el umbral, y más adelante se puede abordar un bloqueo de tiempo para evitar comportamientos maliciosos.

Cartera OKX: (MPC-TSS + Passkey) + (4337 SCA)

Conceptos básicos:

Demo: https://www.okx.com/help/what-is-an-aa-smart-contract-wallet

Cadena: más de 30 cadenas

Clave: MPC-TSS, 2/3

Cuenta: 4337 SCA

Proceso de transacción:

Creación de clave: Al crear una billetera, el OKX transforma una única clave privada en tres partes separadas. La parte 1 se almacena en el servidor de OKX, la parte 2 se almacena en el almacenamiento local del dispositivo del usuario, y la parte 3 es generada por el dispositivo, encriptada y puede ser respaldada en los servicios de nube preferidos del dispositivo, como Google Cloud, iCloud y Huawei Cloud.

Firma de clave: OKX utilizando la tecnología MPC-TSS, el usuario puede obtener la firma completa utilizando dos de las tres partes de la clave privada al firmar la transacción, las partes de la clave nunca se encuentran durante este proceso.

Mecanismo de recuperación:

Mecanismo 2/3: Cuando el usuario cierra la sesión, el dispositivo no está disponible o una de las claves en el dispositivo está comprometida, puede utilizar un nuevo dispositivo para iniciar sesión en la billetera OKX (obtener la parte del servidor) y obtener la parte del servicio en la nube, combinar estas 2 partes para recuperar la billetera, la billetera OKX generará nuevas partes secretas.

Web3Auth: (MPC-TSS + Passkey)+ (EOA/SCA)

Conceptos básicos:

Demo: https://w3a.link/passkeysDemo

Cadena: Todos los EVM y Solana

Clave: MPC-TSS, generalmente 2/3

Cuenta: Cualquier cuenta como EOA, 4337 SCA o SCA general

Proceso de transacción:

Creación de claves: Al crear una billetera, se generan tres partes de clave. La Parte1 es compartida para el inicio de sesión social, el usuario puede escribir su correo electrónico y una red descentralizada de nodos almacena la clave de cada usuario; la Parte2 es una parte de dispositivo que se almacena en el almacenamiento local del dispositivo del usuario; la Parte3 es generada por la computadora local y respaldada por los servicios de nube preferidos por el usuario.

Firma de clave: La arquitectura Web3Auth MPC-TSS garantiza que la clave del usuario siempre esté disponible, incluso utilizando la firma de umbral, las claves nunca se reconstruyen o almacenan en un solo lugar.

Mecanismo de recuperación:

Recuperación de umbral Cuando el usuario cierra la sesión, el dispositivo no está disponible o una de las claves en el dispositivo está comprometida, puede utilizar el método de inicio de sesión social para iniciar sesión en la cuenta webAuthn y obtener el intercambio de nube de clave de paso, combinar estos 2 intercambios para recuperar la billetera.

Protocolo Lit (MPC-TSS + nodos descentralizados + Passkey) + (EOA/SCA)

Información básica:

Demo: https://lit-pkp-auth-demo.vercel.app/

Cadena: La mayoría de la EVM, Cosmos, Solana.

Cuenta: MPC-TSS, 20 de 30 en la red, puede ser adoptado tanto por SCA como por EOA.

Proceso de transacción:

Creación de clave: Cuando el usuario desea crear una billetera, primero selecciona un método de autenticación (clave de paso, inicio de sesión social de oAuth compatible), luego se envía una solicitud al relayer para crear pares de claves y almacenar la lógica de autenticación en el contrato inteligente. Cada par de claves se genera colectivamente por los nodos Lit a través de un proceso llamado Generación de Claves Distribuidas (DKG). Operando como una red descentralizada, 30 nodos Lit se ejecutan dentro de TEE, cada nodo tiene una parte de la clave pero la clave privada nunca existe en su totalidad.

Firma de clave: Al recibir la solicitud, los nodos Lit validan o rechazan de forma independiente la solicitud frente al método de autenticación asignado y, utilizando la tecnología MPC-TSS, se recopilan acciones clave por encima del umbral (20 de 30) para generar una firma y se combinan por el cliente para cumplir con la solicitud.

Mecanismo de recuperación:

Mecanismo 2/3: Utilice los métodos de autenticación almacenados en el contrato inteligente para acceder a la cuenta, los nodos iluminados validan las solicitudes y procederá si más de 2/3 de los nodos confirman.

Conclusión:

Impulsados por el entusiasmo por las soluciones de Capa2, Capa3 y disponibilidad de datos, estamos ansiosos por mejorar el rendimiento de la cadena de bloques. Además, buscamos una seguridad real, combinando la privacidad de la Prueba de Conocimiento Cero con la naturaleza transparente. Todos los esfuerzos apuntan a un objetivo: estar listos para los usuarios reales que interactúan con frecuencia con la cadena de bloques y adoptan la cripto en sus vidas.

Es fácil caer en un sueño de tecnología óptima, pero debemos preguntarnos: ¿qué tipo de experiencia estamos buscando? Visualizamos un mundo donde la Cripto se trata de la intuición en lugar de términos tecnológicos intimidantes, donde un usuario se sumerge en la madriguera del conejo sin dudarlo ni complicaciones.

Imagina a una usuaria Rui: Descubre una fantástica dApp, se registra fácilmente con reconocimiento facial o una huella digital, con la opción de configurar copias de seguridad o tutores. Al interactuar con la dApp, ejecuta transacciones sin problemas, posiblemente con pequeñas tarifas ERC20 o incluso sin ninguna. Más tarde, personaliza la configuración de su billetera, tal vez activando un bloqueo temporal para transacciones automatizadas, agregando otro dispositivo como firmante de respaldo o revisando su lista de tutores.

Nuestros constructores hacen que esto suceda. Integrando WebAuthn y Passkey, mejoramos la gestión de claves privadas, haciéndola segura y fácil de usar. Además de la clave, SCA como entidad abre un mundo de seguridad y funcionalidad personalizada. ¿Y qué pasa con las comisiones de gas? Se vuelven menos gravosas, gracias a los proveedores de Paymaster que pueden crear una 'bóveda' para intercambios o incluso permitir que los anunciantes cubran las comisiones de los usuarios. En el centro de esta evolución, especialmente para la mainnet de Ethereum y sus equivalentes Layer2s, se encuentra ERC4337. Introduce un mempool alternativo que diferencia las transacciones de SCA de las de EOAs, sin grandes cambios en el protocolo. Por otro lado, algunas redes de Capa 2 incluso están adoptando nativamente las SCAs, incorporándolas sin problemas en sus sistemas.

Requiere un esfuerzo tremendo hacer que todo sea fácil. Existen muchos desafíos como reducir las tarifas de implementación, validación y ejecución para SCA; Estandarizar la interfaz para aumentar la interoperabilidad de cuentas; Sincronizar el estado de la cuenta entre cadenas; y muchos más. Crédito a todos los constructores, nos acercamos cada día más a resolver el rompecabezas. Y empresas de cripto como nosotros, SevenX, están listas para ayudar a las grandes empresas a realizar su visión.

Descargo de responsabilidad：

1. Este artículo se reproduce de [CriptoSevenX Ventures]. Todos los derechos de autor pertenecen al autor original [@Rui]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.