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. Vitalik of Ethereum: ETH 2.0 requiere 3 clientes de testnet para ejecutarse de manera continua y estable durante 8 semanas 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 3 clientes para ejecutarse de manera estable en la red de prueba durante 8 semanas consecutivas antes de que pueda 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 el dos son fundamentalmente diferentes, ETH 2.0 Se establecerá 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 ha lanzado una nueva herramienta para cargar archivos a IPFSEthereum Name Service (ENS) ha lanzado una nueva característica que permite a los usuarios crear sitios web descentralizados en su ENS Manager. 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 el hash 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 sitios web descentralizados. 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. La organización humanitaria EOS CARE utilizará Celo blockchain en proyectos latinoamericanos: La organización humanitaria CARE anunció una asociación con la plataforma financiera descentralizada Celo (CELO) para desarrollar su primera plataforma basada en blockchain en América Latina. CARE dice que su objetivo es utilizar la cadena de bloques Celo para permitir una entrega de ayuda más rápida, económica y rastreable. CARE afirma que no tener un intermediario en la distribución de fondos permitirá que se utilicen más fondos para su misión. (Finbold) [2021/8/12 1:51:35] Actualización de la aplicación EOS Authenticator Administrador de claves privadas de EOS 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 Gestión de claves 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 estará disponible 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 desarrollando activamente un producto que utilizará 4 cadenas privadas independientes para la comunicación. Con este fin, estamos mejorando la forma en que se envían y verifican los mensajes en las cadenas. Polkadot Polkadot formó el equipo de auditoría de seguridad de Génesis en Web3 Foundation, y creemos que habrá una red donde los usuarios, en lugar de las empresas, administrarán sus datos. Con esta creencia, estamos diseñando e invirtiendo en la próxima generación de Internet Web 3.0. En esta red, la tecnología blockchain creará un sistema "sin confianza" donde no habrá intermediarios. 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. PandaID y Conflux cooperan para proporcionar a los usuarios servicios de cadena de bloques compatibles: según las noticias oficiales, PandaID y Conflux cooperan para proporcionar a los usuarios servicios de cadena de bloques compatibles. Los productos futuros enriquecerán aún más los servicios y apoyarán el desarrollo de la ecología de la industria NFT. Panda ID proporciona autenticación de identidad distribuida basada en web3.0 y utiliza tecnología blockchain para proporcionar a los usuarios un sistema de cuenta unificado. PandaID construye la infraestructura subyacente en la cadena de bloques, proporcionando la base de autenticación de identidad necesaria para el desarrollo de NFT y metaverso. PandaID implementa estrictamente el principio NTK y no recopila información personal como nombres de usuario, direcciones, direcciones de correo electrónico, direcciones IP y números de teléfono; tampoco recopila información de transacciones, saldos ni almacena activos de los usuarios. [2021/7/9 0:39:42] Esto también significa que la seguridad de la cadena de bloques es extremadamente importante. Una cadena es tan fuerte como su eslabón más débil, y 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 defendemos el principio de 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 fuga de información son solo algunos de los problemas que Parity y Web3 Foundation han descubierto y están trabajando para solucionarlos. La ventana de lanzamiento de la red principal de 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. Según los resultados, los desarrolladores decidieron que tenían que hacer algunos cambios antes de pasar a la segunda fase de la red de prueba. MakerDAO inicia una votación ejecutiva sobre si aprobar la propuesta del paquete del ciclo de gobernanza de marzo: Jinse Finance informó que, según el blog oficial, el facilitador de gobernanza de MakerDAO y el equipo de contratos inteligentes de la Fundación Maker han incorporado una votación ejecutiva en el sistema de votación sobre si aprobar el Consejo del Paquete de Ciclo de Gobernanza de Marzo. Si se aprueba esta propuesta ejecutiva, el siguiente estado de MIP cambiará: el conjunto de MIP de la unidad central pasará al estado Aceptado; las revisiones relacionadas con el conjunto de MIP de la unidad principal se moverán al estado Aceptado; MIP43, Módulo de préstamo a plazo se moverá al estado "Aceptar"; MIP45 , la liquidación 2.0 entrará en el estado de aceptación; MIP46, el grupo de propuesta de parámetros pasará al estado de "aceptación"; MIP47, la gestión de carteras de firmas múltiples de MakerDAO pasará al estado de "aceptación", etc. [2021/3/23 19:08:32] Filecoin fue desarrollado por Protocol Labs y se basó en el sistema de archivos interplanetarios (IPFS), una red de almacenamiento de datos entre pares, diseñada para permitir a los usuarios intercambiar espacio de almacenamiento en un espacio abierto mercado. 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 propuestos 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 segunda fase de la red de prueba se lanzará la semana del 11 de mayo, mientras que la red principal se ejecutará del 20 de julio al 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”, explicó el comunicado. 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 respaldo. Lamentablemente, a la estructura "tal como está" le falta un componente clave de un ecosistema descentralizado exitoso, a saber, la 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 identificar si A es un usuario válido en la red. Esto es especialmente problemático cuando en lugar de implementar una red específica del usuario 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), lanzamos una red genérica sin problemas con los usuarios que interactúan con cualquier aplicación implementada en la 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). Para 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: Proxy de código de cadena: 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 por el 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.

Tags：

Huobi App