Technology Weekly | El sistema de nombres de dominio Ethereum ENS lanza nuevas herramientas

El Technology Weekly de esta semana contiene noticias relacionadas con la tecnología sobre las cuatro redes de Ethereum, Polkadot, Filecoin e Hyperledger.

Etéreo

V God: ETH 2.0 necesita 3 clientes de testnet para ejecutarse de manera estable durante 8 semanas consecutivas antes de que pueda lanzarse

En un evento reciente de AMA en el foro de Reddit, el cofundador de Ethereum, Vitalik Buterin, los investigadores de ETH 2.0, Danny Ryan y Justin Drake, revelaron que ETH 2.0 requiere que tres clientes se ejecuten de manera estable en la red de prueba durante 8 semanas consecutivas antes de poder lanzarse. Además, en otro programa de podcast, el partidario de Ethereum, Ryan Sean Adams, cree que ETH 2.0 se lanzará pronto. Al mismo tiempo, dijo que la gente no tiene que preocuparse porque ETH 2.0 repetirá los errores de Lightning Network, porque los dos son fundamentalmente diferentes, ETH 2.0 Se construirá una nueva plataforma independiente que eventualmente reemplazará a la cadena principal, mientras que Lightning Network se basa en la cadena de bloques de Bitcoin.

El sistema de nombres de dominio Ethereum ENS lanzó una nueva herramienta que puede cargar archivos a IPFS con un solo clic

El Servicio de nombres de Ethereum (ENS) ha lanzado una nueva función que permite a los usuarios configurar sitios web descentralizados dentro de su Administrador de ENS. La característica hace que sea más fácil que nunca cargar y acceder a contenido resistente a la censura usando Ethereum. ENS Manager ahora permite cargar contenido a través de una integración con Temporal.

Además, el equipo de ENS del sistema de nombres de dominio de Ethereum anunció el lanzamiento de una nueva herramienta que permite a los usuarios cargar archivos en IPFS y guardar hashes de IPFS directamente en el registro de ENS del usuario. Antes del lanzamiento de la herramienta, los usuarios tenían que cargar archivos a IPFS en un lugar y luego actualizar sus registros ENS en otro. Esta herramienta puede simplificar enormemente el proceso y facilitar que las personas inicien un sitio web descentralizado. Si los usuarios necesitan usar esta herramienta, primero deben descargar un navegador Web3, preparar una pequeña cantidad de ETH para el pago de las tarifas de transacción de la red Ethereum y un nombre .ETH.

EOS

Actualización de la aplicación EOS Authenticator

EOS Private Key Manager La aplicación EOS Authenticator se actualizó y la nueva versión ahora admite las siguientes operaciones: importar claves privadas como archivos de billetera, iCloud y administración de claves privadas. Además, el navegador bloks.io también es totalmente compatible con el inicio de sesión de la aplicación EOS Authenticator.

BM: Eosio se podrá utilizar en aplicaciones empresariales

El fundador de EOS, Daniel Larimer (BM), tuiteó esta semana que Eosio se puede usar en aplicaciones empresariales sin el uso de tokens y tiene una confirmación de terminal de 0,5 segundos (finalidad). Hay muchos beneficios al combinar una base de datos de alto rendimiento y un registro de auditoría. Estamos trabajando activamente en un producto que utilizará 4 cadenas privadas separadas para la comunicación. Con este fin, estamos mejorando la forma en que se envían y verifican los mensajes en las cadenas.

Poca

Polkadot forma el equipo de auditoría de seguridad de Genesis

El número de transacciones no confirmadas en toda la red Bitcoin es 4725: Jinse Finance informó que, según los datos de BTC.com, el número de transacciones no confirmadas en toda la red Bitcoin es actualmente 4725, la potencia informática total de la red es 232,34 EH/s y la tasa de transacción de 24 horas es de 2,98 transacciones/s, la dificultad actual de toda la red es de 32,05 T, y se predice que la próxima dificultad aumentará en un 0,19 % a 32,11 T, y quedan 10 días y 3 horas antes el ajuste. [2022/9/18 7:03:52]

En Web3 Foundation creemos en una red donde los usuarios, no las empresas, gestionen sus datos. Con esta creencia en mente, estamos diseñando e invirtiendo en la próxima generación de Internet, la Web 3.0. En esta red, la tecnología blockchain creará un sistema "sin confianza" donde no existirán los intermediarios existentes. Dicho esto, no tenemos que confiar en las buenas intenciones de una institución, empresa o proveedor de servicios. En cambio, las reglas y los reglamentos en sí están integrados en el sistema para que, sin importar quién gobierne o los arquitectos, todo el sistema continúe funcionando de acuerdo con esas reglas.

Esto también significa que la seguridad de la cadena de bloques es de suma importancia. Una cadena es tan fuerte como su eslabón más débil, cualquier debilidad en el sistema afecta al conjunto.

Es por eso que estamos invirtiendo mucho en auditorías de seguridad previas a la génesis, así como en cada paso del camino: el tiempo de ejecución y el host de Polkadot, la biblioteca JS de Polkadot, la red de Kusama y los implementadores de validadores.

Hemos reunido el mejor equipo para auditar para nosotros. Entre estos se encuentran Atredis, NCC Group, Open Zeppelin, SR Labs y Trail of Bits.

En la Fundación Web3, creemos en la transparencia. Continuaremos publicando esta serie de blogs, dando a conocer nuestros hallazgos y avances, para solucionar los problemas identificados. Incluyendo ataques de spam, problemas de phishing y hallazgos generales de auditoría de seguridad, la exposición accidental de puertos de divulgación de información son solo algunos de los problemas que Parity y Web3 Foundation han descubierto y están trabajando para solucionarlos.

Filecoin

La ventana de lanzamiento de la red principal para la red de almacenamiento descentralizado Filecoin se retrasará aún más, esta vez confirmada entre finales de julio y finales de agosto.

En una nueva actualización, el equipo de Filecoin reveló que el proyecto realizó la primera ronda de su auditoría de seguridad de protocolo interno. Con base en los resultados, los desarrolladores decidieron que antes de pasar a la segunda fase de la red de prueba, tenían que hacer algunos cambios.

Desarrollado por Protocol Labs, Filecoin se basa en el sistema de archivos interplanetarios (IPFS), una red de almacenamiento de datos entre pares, y tiene como objetivo permitir a los usuarios intercambiar espacio de almacenamiento en un mercado abierto. El proyecto fue una de las mayores ventas de tokens de 2017 y recaudó más de $200 millones de inversores institucionales acreditados.

Originalmente, se suponía que la red principal se lanzaría en marzo de 2020. En febrero, el equipo retrasó el lanzamiento hasta el 15 y el 17 de julio, citando el brote de coronavirus en China como la razón principal por la que no se completó su trabajo. Ahora, los desarrolladores dicen que tienen más tiempo para abordar los cambios que surgieron durante la revisión.

"Hemos redactado una serie de cambios de protocolo para garantizar que nuestra estructura de lanzamiento de red principal sea segura y económica”, dijo el comunicado. Los desarrolladores principales del proyecto los agregarán a las dos implementaciones del protocolo, Lotus y go.filecoin.

Para darle a la comunidad la oportunidad de participar en la línea de tiempo, el equipo de desarrollo de Filecoin realizó una encuesta para que los miembros de la comunidad votaran en tres escenarios diferentes con respecto a la fecha de lanzamiento de Testnet Phase 2 y mainnet.

Después de tener en cuenta los comentarios de la comunidad, el equipo se decidió por una estimación "conservadora" de que la red de prueba de la Fase 2 se lanzará la semana del 11 de mayo, mientras que la red principal se ejecutará desde el 20 de julio hasta el 21 de agosto. La hoja de ruta de actualización se puede ver en el proyecto Filecoin.

“Esta opción nos permitirá realizar primero los cambios de protocolo más críticos y luego implementar el resto como actualizaciones de protocolo durante la red de prueba”, explica el comunicado.

Hiperlibro

Hyperledger publicó un artículo esta semana para interpretar TrustID

TrustID: un nuevo enfoque para la gestión de identidades de usuarios estructurales

No hay duda de que Hyperledger Fabric brinda a las empresas una base central de descentralización y confianza. Abre la puerta al desarrollo de nuevos casos de uso y modelos de negocio basados ​​en los beneficios de la tecnología DLT. Fabric admite activos digitales, lógica distribuida a través de cadenas, privacidad y otros escenarios que usan canales (como la recopilación de datos privados) y el uso de consenso personalizado a través de políticas de aprobación. Lamentablemente, a la estructura "tal cual" le falta un componente clave de un ecosistema descentralizado exitoso, una identidad descentralizada.

Fabric utiliza certificados X.509 para autenticar a cada entidad y miembro de la red. Esto es realmente útil para entornos corporativos, ya que las organizaciones pueden usar su infraestructura de CA existente para emitir nuevos certificados para usuarios, pares y aplicaciones. Por lo tanto, siempre que el certificado sea emitido por una CA de confianza en la red (es decir, una CA de una organización MSP válida en el sistema), su titular tendrá autoridad para interactuar con la red.

Este esquema de gestión de identidades parece ser adecuado para una variedad de casos de uso, pero el problema surge cuando se requiere la continuidad del usuario entre diferentes organizaciones. Si el Usuario A posee un certificado válido emitido por Org1, puede interactuar con la red a través de los pares de Org1, o al menos por entidades que saben cómo verificar su "cadena de confianza". Sin embargo, si el usuario A interactuara con la red a través de una aplicación Fabric en Org2, los pares de Org2 no podrían reconocer que A es un usuario válido en la red.

Esto es especialmente problemático cuando, en lugar de implementar redes específicas de usuarios con organizaciones bien definidas y sus relaciones (los usuarios pertenecen a una organización y solo interactúan a través de la infraestructura de esa organización), iniciamos una red genérica sin problemas con los usuarios que interactúan con cualquier aplicación implementada en el red. Por eso nos propusimos desarrollar TrustID, un intento de descentralizar Identity for Fabric.

En Telefónica, hemos estado construyendo TrustOS, una capa de abstracción para plataformas blockchain que permite a las empresas y desarrolladores implementar casos de uso descentralizados sin tener que preocuparse por las complejidades subyacentes de las redes DLT. Uno de los motores centrales de TrustOS es la red Hyperledger Fabric de propósito general. La primera versión de TrustOS aprovechó la administración de identidades predeterminada de Fabric, por lo que los nuevos usuarios se autenticaron a través de certificados emitidos por Telefónica. Inicialmente, esto tenía sentido porque éramos la única organización en la red que implementaba la aplicación. Desafortunadamente, cuando comenzamos a registrar nuevas organizaciones y aplicaciones en el sistema, nuestros usuarios comenzaron a sufrir los problemas de iteración antes mencionados. Cualquier usuario que quiera interactuar con más de una organización debe tener un certificado válido firmado por cada organización en la red con la que se interactuará la infraestructura. En resumen, la gestión de las identidades de los usuarios es una pesadilla en términos de operaciones y experiencia de usuario.

Entonces, decidimos diseñar TrustID como un módulo de identidad independiente de TrustOS. Hemos adoptado un enfoque de identidad descentralizado en nuestro diseño, donde los usuarios (y los servicios) se identifican mediante un DID.

Estos DID siguen los estándares W3C y se utilizan como ID únicos para identificar a los usuarios. Un DID agrega toda la información pública necesaria para autenticar a un usuario (es decir, su clave pública o certificado X.509).

Con el fin de identificar de forma única los códigos de cadena y los servicios implementados en TrustOS, también decidimos darles DID para que puedan ser descubiertos y accedidos sin problemas, incluso si "existen" en canales separados que no comparten todas las organizaciones de la red.

La autenticación y la gestión de todas las identidades en el sistema se realizan en cadena a través del "código de cadena de identidad". Este código de cadena consta de las siguientes partes:

Chaincode Proxy: recibe y enruta todas las transacciones autenticadas por TrustID. Es responsable de autenticar a los usuarios, interactuar con el registro de ID y enrutar las llamadas de los usuarios a códigos de cadena externos. También hace cumplir las políticas de acceso requeridas por diferentes organizaciones.

Registro de Usuario: Almacena el DID de cada usuario. Implementa operaciones básicas de setter y getter y aplica los permisos de acceso necesarios para cada organización.

Registro de Servicios: Rol de Registro para el servicio de pago.

Código de cadena de servicio externo: esto garantiza que el código de cadena de servicio con el que los usuarios desean interactuar se pueda implementar en cualquier canal. Tras la verificación exitosa de la solicitud, el código de cadena del proxy es responsable de reenviarles la transacción.

Entonces, si el usuario A quiere comenzar a interactuar con la red, solicita generar un nuevo DID. La clave asociada para este DID puede ser un X.509 existente emitido por una organización válida, o incluso una clave pública relacionada con Ethereum (internamente usamos todos los JWS, JWE, JWK, secp256k1, etc.). Los RFC hacen que nuestra infraestructura Fabric sea compatible con identidades de cualquier naturaleza con interoperabilidad). Esta solicitud de generación de DID debe ser verificada por una organización válida de la red. Después de la verificación, cada transacción firmada por el usuario A y dirigida a través del proxy CC se autenticará con éxito y se delegará al código de cadena correspondiente.

Desarrollamos TrustID para simplificar la gestión de identidades en el contexto de TrustOS. Los usuarios no tienen que tener un conjunto diferente de credenciales para cada red o aplicación descentralizada con la que interactúan. Las mismas credenciales utilizadas para acceder a los bitcoins que posee y administrar tokens en Ethereum le permitirán actualizar el estado de sus activos de Fabric o lanzar un mercado secundario en TrustOS. Este es el principio detrás de TrustID. Además, impulsar la gestión de identidad de usuario de Hyperledger Fabric en la cadena ha abierto la puerta a consecuencias emocionantes como la interoperabilidad de servicios entre redes o el uso de Fabric como un sistema de autenticación de propósito general, pero en una publicación posterior Más sobre esto en .

Tags：

FTT