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. The Sandbox: La cuenta oficial de Instagram puede estar hackeada, atención a la prevención de riesgos: El 4 de agosto, The Sandbox tuiteó que se dio cuenta de que su cuenta oficial de Instagram pudo haber sido hackeada. No haga clic en ningún enlace en la página de Instagram de The Sandbox. No se comunique con personas en sus páginas de Instagram que digan ser de The Sandbox. El equipo de seguridad de Sandbox está investigando el asunto. [2022/8/4 12:02:11] 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. 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 empresarial correcta y autentica correctamente al 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. CEO de BlockFi: El intercambio de criptomonedas FTX no adquirirá la empresa hasta el otoño de 2023: Según las noticias del 13 de julio, el CEO de BlockFi, una plataforma de préstamo y comercio de criptomonedas, dijo que el intercambio de criptomonedas FTX no adquirirá la empresa hasta el otoño de 2023. La transacción de FTX no dañará los intereses de los accionistas. [2022/7/13 2:10:44] Es posible 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án como un señuelo 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. La seguridad y el determinismo son difíciles de lograr, por lo que la tecnología se construye en capas que abstraen los detalles. EOSIO combina un entorno de ejecución determinista (WebAssembly) con una base de datos rápida en el mismo proceso. Todas las acciones de los usuarios están firmadas por sus propias claves privadas y registradas en una base de datos replicada y distribuida con la capacidad de realizar compromisos públicos para bloquear encabezados. Es solo cuestión de tiempo antes de que los marcos como EOSIO se vuelvan tan poderosos y fáciles de desarrollar como los sistemas inseguros tradicionales. En muchos sentidos, la arquitectura de EOSIO ya tiene más rendimiento que los sistemas tradicionales porque coloca la lógica de la aplicación en el mismo espacio de proceso que la base de datos en memoria. Esto crea procedimientos almacenados deterministas. En los próximos años, Block.one tiene como objetivo agregar herramientas e interfaces que harán que la implementación de aplicaciones empresariales en cadenas de bloques sea tan fácil (o más fácil) como implementarlas en arquitecturas de aplicaciones empresariales tradicionales. Está claro que la adopción de la tecnología blockchain debe ser una prioridad para las agencias gubernamentales, las empresas públicas y las empresas con responsabilidades para prevenir el fraude o realizar informes financieros. En mi opinión, no adoptar la tecnología blockchain en los próximos años es como si los bancos no adoptaran SSL, una vez que la tecnología se use ampliamente, no usar la tecnología blockchain se considerará negligencia. Es hora de ponerse en movimiento. Su empresa y sus usuarios no estarán seguros sin cambios fundamentales en la forma en que se construyen las aplicaciones. Cada día que se retrasa pone su empresa en riesgo de fraude o piratería informática

Tags：

Uniswap