BM, fundador de EOS: ¿Por qué dice que la seguridad de todas las empresas depende de la cadena de bloques?

Escrito al frente: El autor de este artículo es Daniel Larimer, el fundador de EOS. En su artículo, analizó las fallas en la infraestructura y el diseño de las bases de datos en la Internet tradicional y señaló que la cadena de bloques es la mejor solución: el marco abierto de la cadena de bloques como EOSIO hace que sea innecesario que los desarrolladores construyan aplicaciones seguras. El programa recrea la "base de datos", porque todos los usuarios usan sus claves privadas para firmar sus propias acciones, que pueden rastrearse y verificarse. Uno de los objetivos de B1 en el futuro es agregar herramientas e interfaces para que el proceso de implementación de servicios en blockchain sea similar (o incluso más simple) a la implementación de servicios en Internet tradicional. Las infraestructuras de aplicaciones web tradicionales se diseñaron con la seguridad como una idea de último momento y, durante los últimos 25 años, muchas empresas han intentado parchear una arquitectura fundamentalmente insegura. Esta arquitectura presupone que se puede confiar y proteger el servidor cuando se diseña, pero los años de experiencia nos dicen que ningún servidor es seguro, y mucho menos los ataques internos. En otras palabras, el servidor está básicamente centralizado. Solíamos pensar que el "problema" era la conexión entre el usuario y el servidor, así que introdujimos SSL y HTTPS. Pero luego descubrimos que los piratas informáticos comprometerían la base de datos y robarían las contraseñas. Entonces comenzamos a almacenar hashes de contraseñas, pero luego descubrimos que los piratas informáticos usaban contraseñas de fuerza bruta después de robar los hashes. Luego, introdujimos un mecanismo de cambio de contraseña para cambiar la contraseña con fuerza bruta, y muchas otras medidas como esta. Las empresas gastan miles de millones de dólares en la protección de servidores y bases de datos y, a pesar de todos los esfuerzos, todavía no existe una manera fácil de auditar los sistemas y garantizar que las empresas funcionen como se espera. Block.one está creando un software de cadena de bloques para mantener las bases de datos y las cuentas de usuario a salvo de accesos no autorizados y modificaciones inexplicables. Con una cadena de bloques, en lugar de simplemente autenticar las conexiones del servidor, los usuarios tienen acceso a claves privadas de alta seguridad almacenadas en hardware seguro que se utilizan para firmar cada interacción del usuario. Blockchain crea un registro inmutable, estableciendo un orden absoluto y determinista en el que se recibe la entrada del usuario, mientras que los contratos inteligentes proporcionan una lógica comercial determinista, lo que garantiza la coherencia en todos los sistemas. El futuro de Block.one es eliminar las contraseñas y las costosas auditorías, ahorrar a las empresas miles de millones de dólares, prevenir el robo de identidad y brindar una mayor confiabilidad y auditabilidad. Durante años, he creído que cada sitio web multiusuario podría beneficiarse de un backend de blockchain. Al contrario de lo que mucha gente cree, las cadenas de bloques no tienen que ser bases de datos lentas e ineficientes, ni necesitan operar de forma abierta y resistente a la censura. Las cadenas de bloques pueden proporcionar mejoras importantes en la seguridad, la auditabilidad, la transparencia y la integridad de los procesos comerciales, incluso si la cadena de bloques es operada en su totalidad por la propia empresa, y todo lo que contiene se mantiene privado. Este artículo tiene como objetivo revelar el verdadero valor de la cadena de bloques en el entorno empresarial y señalar la dirección para el desarrollo de la industria de la cadena de bloques. La circulación de la moneda estable compatible HUSD superó los 300 millones de dólares estadounidenses, convirtiéndose en la cuarta moneda estable compatible más grande del mundo: el 8 de enero, según los últimos datos de la cadena, la circulación de la moneda estable compatible HUSD superó los 300 millones de dólares estadounidenses. y la circulación acumulada supera los 3.350 millones de dólares estadounidenses, alcanzando ambos máximos históricos. Al mismo tiempo, la circulación de la versión HUSD (HRC20) apoyada por la cadena ecológica Huobi Heco ha batido repetidamente nuevos máximos, alcanzando los 160 millones de dólares estadounidenses. En términos de aplicaciones DeFi, HUSD ha sido respaldado por Curve, Uniswap, YFII, Harvest, Nest y otras plataformas y proyectos DeFi conocidos, y ha sido ampliamente utilizado en la cadena ecológica Huobi Heco. La circulación de HUSD y los datos en la cadena han aumentado rápidamente, superando a la antigua moneda estable TUSD y convirtiéndose en una de las cuatro monedas estables más importantes del mundo (las otras tres son USDC, BUSD y PAX). HUSD es una moneda estable compatible emitida por Stable Universal, que está anclada 1:1 con el dólar estadounidense. HUSD se ha implementado en el comercio de activos digitales, pagos, DeFi y otras aplicaciones. El equipo de HUSD se dedica a brindar a los usuarios servicios de activos digitales seguros, estables y convenientes. [2021/1/8 15:40:30] En la industria de la cadena de bloques, muchas personas creen que la cadena de bloques solo creará ventajas cuando conecte a partes que no confían entre sí. Creen que la tecnología de base de datos tradicional ya puede hacer todo el trabajo necesario para asegurar el negocio. En otras palabras, creen que la replicación de base de datos tradicional y las garantías de "integridad de datos" son suficientes. En el proceso, ignoran o ignoran las diferentes garantías de seguridad e integridad proporcionadas por la cadena de bloques: 1. Compromiso con una secuencia global de eventos 2. Ejecución determinista de la lógica comercial 3. Lógica comercial e integridad de los datos Acoplamiento estrecho 4. Elimina las contraseñas en arquitecturas de aplicaciones empresariales, la lógica empresarial está separada de la base de datos. Normalmente hay un servidor de aplicaciones, como Node.js o J2EE, que proporciona la contraseña para modificar la base de datos. La función del servidor Node.js es autenticar a los usuarios a través de contraseñas o mecanismos de autenticación de múltiples factores. Una vez que el servidor de aplicaciones ha autenticado al usuario, emite un token de sesión que se utiliza para autenticar futuras interacciones del usuario hasta que se agote el tiempo de espera o cambie algún elemento de la sesión (como la IP). Obviamente, este diseño tradicional realiza todas las operaciones de la base de datos a través de un solo inicio de sesión/contraseña administrado por el servidor de aplicaciones. Por uso final, el servidor de aplicaciones es responsable de implementar el mecanismo de autenticación. Obviamente, suele haber varios usuarios con acceso a nombres de usuario y contraseñas. Un administrador de base de datos puede asignar y revocar credenciales a muchos servidores de aplicaciones o individuos diferentes. Los sistemas avanzados garantizan que, en un sistema escalable, cada servidor de aplicaciones tenga su propio nombre de usuario y contraseña y, en algunos casos, incluso utilice infraestructura de clave pública (PKI) y módulos de seguridad de hardware (HSM). Sin embargo, incluso aquí, la base de datos solo autentica las conexiones con el servidor de aplicaciones. Para proporcionar un registro de auditoría, debe registrar todo el flujo de datos de una conexión segura. Sin embargo, incluso este registro solo puede registrar "operaciones de lectura y escritura" solicitadas por el servidor de aplicaciones, que ha perdido toda la información sobre la intención original del usuario. Bifrost Tyrone: Acaba de terminar la red de prueba de Asgard CC3 y el equipo se está preparando para PLO: según las noticias oficiales, el tema de la octava edición del "Consenso 52" de CoinW "Polkadot's Evolutionary Road-Can Polkadot inicia la próxima ronda de DeFi ¿Boom?" En el tema de AMA, Bifrost Tyrone mencionó que, como una de las partes del proyecto apoyadas por Web3 Foundation en el ecosistema de Polkadot, resuelve principalmente los problemas de alto umbral cognitivo, falta de liquidez, gobernanza y conflicto de intereses en Stake. La dirección de aplicación de Bifrost es apostar sin bloqueo, reducir el umbral de participación y proporcionar ingresos por participación. Acabamos de terminar la red de prueba Asgard CC3 la semana pasada. Asgard es la red de preproducción de Bifrost. Los socios pequeños pueden conectarse a la red de Asgard para realizar pruebas antes de conectarse oficialmente a la red principal de Bifrost para eliminar los riesgos comerciales. La red de prueba Asgard CC3 tiene un crecimiento de datos considerable en comparación con CC2. Al mismo tiempo, se detectó una pequeña falla en el intercambio vEOS, que ahora se ha localizado y reparado. Esta es también la importancia de la red de prueba en sí. Ahora, el equipo se está preparando para la solución de liquidez PLO (Oferta de arrendamiento de Parachain) y se está preparando para solicitar la segunda subvención de la Fundación WEB3. [2020/11/13 20:45:33] Los auditores que revisan un sistema de este tipo no tienen forma de saber si el servidor de aplicaciones (por ejemplo, Node.js) sigue la lógica comercial correcta y autentica correctamente la identidad del usuario final. El proceso de Node.js puede registrar las operaciones del usuario en la base de datos, lo cual es conveniente para que los auditores repliquen los mismos cálculos, pero dichos registros no son inmutables y no existe una verificación de autenticación independiente, por lo que es imposible saber que el usuario final tiene autorizó realmente una determinada conducta. Se podría intentar registrar la conexión de cada usuario, pero dado que los usuarios a menudo transmiten sus contraseñas a través de la conexión, estos registros terminarían siendo un trampa para filtrar información del usuario. Los sistemas más sofisticados pueden cifrar estos registros para que solo los auditores puedan leerlos. Suponiendo que el registro de auditoría no haya sido manipulado, los auditores deberán ejecutar la misma secuencia de operaciones a través de la lógica de la aplicación para verificar que el estado final de la base de datos coincida. Esto significa que los servidores de aplicaciones deben implementarse de manera determinista. Si bien escribir código determinista puede parecer sencillo, prácticamente todos los lenguajes informáticos comunes son no deterministas porque permiten a los desarrolladores acceder a datos almacenados fuera de las bases de datos. Podría ser algo tan simple como una marca de tiempo, una dirección de memoria, una variable de entorno, una dirección IP o algo más sutil como el comportamiento del punto flotante en el hardware o el orden de inserción de una tabla hash. En muchos casos, acceder a las variables de memoria del servidor de aplicaciones de ejecución prolongada es suficiente para introducir el no determinismo. La acción de iniciar/detener el servidor de aplicaciones se debe registrar y replicar; de lo contrario, cada acceso a la memoria local puede no ser determinista durante la reproducción. La verdad es que escribir código determinista es un desafío para los mejores desarrolladores, entrenados en errores comunes, para buscar activamente el no determinismo. A un desarrollador de aplicaciones empresariales típico le resultará difícil o poco práctico escribir código de manera determinista. Si asumimos además que el código de la aplicación es determinista, que las aplicaciones registran fielmente los eventos de los usuarios, aún enfrentamos el desafío de rastrear las versiones de código implementadas. Las aplicaciones son dinámicas y se actualizan con frecuencia, por lo que el propio código de la aplicación también debe formar parte del estado de la base de datos, y sus actualizaciones deben administrarse y registrarse con la misma seguridad y auditabilidad que las acciones del usuario. Luego, los auditores deben tener copias de todas las versiones del código del servidor de aplicaciones y reproducir la entrada del usuario (y el código de reinicio) según sea necesario a través de cada actualización de versión. Incluso si un solo servidor de aplicaciones pudiera operar de manera determinista, tanto en términos de instalación como de implementación, aún sufriría un importante problema de escalabilidad. Solo una instancia del servidor de aplicaciones puede operar en la base de datos. El acceso paralelo se puede lograr con bloqueos complejos, pero incluso las condiciones de carrera en los bloqueos deben documentarse y replicarse, o dos instancias de lógica de aplicación con diferentes variables locales pueden producir resultados indefinidos. En este momento, las personas pueden renunciar a la certeza por completo, pero después de la ausencia de certeza, se acumulará gradualmente una gran cantidad de sesgo en el conjunto de datos final. Los auditores se verán obligados a utilizar la lógica difusa y la coincidencia aproximada, y todos tendrán que confiar en que la "lógica difusa" es lo suficientemente buena. Por supuesto, lo único que niega todo el esfuerzo que implica escribir e implementar código determinista es que el administrador de la base de datos modifique directamente la base de datos sin rastrearla. En algunos casos, las actualizaciones cuidadosas del estado y el registro de entrada del usuario pueden crear dos estados distintos de la base de datos, cada uno de los cuales supera las pruebas deterministas pero sigue teniendo resultados diferentes e irreconciliables. Por ejemplo, suponga que un profesor envía la calificación F de un estudiante al sistema, y ​​luego el estudiante puede piratear o sobornar la base de datos para cambiar su calificación y el registro presentado por el profesor. El objetivo final de cualquier sistema multiusuario que valore la integridad es garantizar que la entrada del usuario no se pueda falsificar. El uso de nombre de usuario/contraseña u otra autenticación subjetiva de múltiples factores (como SMS o verificación de Google) depende del servidor para juzgar si la contraseña coincide o si se ingresó el código de SMS/enlace de correo electrónico/código de verificación correcto. Claramente, este es un gran problema para la integridad del sistema, y ​​daré un ejemplo real de lo malos que son estos sistemas. En 2016, abrí una cuenta con un intercambio de criptomonedas, que luego fue pirateada y los piratas informáticos robaron decenas de miles de dólares en bitcoins. Recibí un total de 4 correos electrónicos, el primero fue un correo electrónico de "restablecimiento de contraseña" y luego otro correo electrónico que decía que mi contraseña se había restablecido correctamente. Luego recibí un correo electrónico pidiéndome que confirmara mi retiro de bitcoin (con un código/enlace). Luego recibí una notificación de que se completó mi procedimiento de retiro. A primera vista, parece que mi correo electrónico ha sido pirateado, pero esto no es posible porque uso la autenticación multifactor. La página Seguridad de mi buzón no muestra ningún acceso no autorizado. También puedo saberlo porque Google registra y muestra todas las direcciones IP y dispositivos que acceden a mi buzón. De hecho, el atacante interceptó el correo electrónico incluso antes de que llegara a mi buzón. El servidor de aplicaciones no tiene forma de saber que el correo electrónico fue interceptado, por lo que incluso si el atacante solo tiene el código único generado por el servidor de aplicaciones, aún puede obtener autorización para restablecer la contraseña y retirar monedas. La misma vulnerabilidad también podría usarse para SMS u otras tecnologías que dependen de claves privadas controladas por el usuario. Una cuenta de usuario verdaderamente segura es aquella que emplea claves privadas basadas en hardware como credenciales de inicio de sesión para todos los usuarios, y emplea un proceso sólido y lento para facilitar restablecimientos seguros en caso de pérdida de la clave de hardware. En este punto, la aplicación empresarial multiusuario puede firmar cada solicitud de usuario con la clave privada del usuario, registrar esta solicitud firmada en la base de datos y procesarla mediante un código determinista. Incluso esto no proporciona la integridad que uno esperaría, ya que las solicitudes de los usuarios aún podrían eliminarse, con efectos secundarios. Imagínese cuando un oficial de policía envía su boleto y luego todos los estados producen la solicitud, puede piratear la base de datos de la policía y eliminar la solicitud que firmó. En este punto, un ingeniero inteligente declarará que todos los problemas que planteo se pueden resolver cambiando la lógica de la aplicación. Tiene razón, un desarrollador de aplicaciones maduro puede usar bases de datos tradicionales, servidores de aplicaciones tradicionales y primitivas criptográficas comunes para construir un sistema auditable y relativamente seguro. Por la misma lógica, un ingeniero experto podría afirmar que las bases de datos son completamente innecesarias y que todo debería construirse directamente en el sistema de archivos. Otro ingeniero podría señalar que podemos escribir código desde cero y ya no depender de los marcos de servidores de aplicaciones como Node.js y J2EE, lo que mejorará el rendimiento. Es como si todo estuviera hecho con tecnología de bajo nivel, y también podemos diseñar los transistores de mejor rendimiento. Señalo este extremo porque destaca la utilidad real de los marcos de trabajo de alto nivel para acelerar y asegurar el desarrollo de nuevas aplicaciones. Muy pocas personas escriben sus propias bibliotecas criptográficas o algoritmos, y las personas que lo hacen son expertos o se convierten en un mal ejemplo cuando sus sistemas son pirateados. El costo de desarrollar/redesarrollar todo desde cero puede hacer que cada aplicación sea más costosa que construir sobre un marco probado. Los marcos de desarrollo como blockchain y EOSIO existen para que los desarrolladores de aplicaciones no tengan que recrear "bases de datos" para crear aplicaciones seguras

Tags：

Shiba coin