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. EOS superó la marca de $ 4 con un aumento intradiario del 5,56 %: según datos de Huobi Global, EOS aumentó a corto plazo y superó la marca de los $ 4. Ahora se reporta en $ 4,0001, con un aumento intradiario del 5,56 %. el mercado fluctúa mucho, así que haga un buen trabajo en el control de riesgos. [2021/3/13 18:42:39] 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. BM: EOSIO puede completar todas las funciones en ETH, y el producto es excelente: el internauta de Twitter Shengwu1893 dijo que una gran persona debe crear un gran producto antes de que la gente lo conozca y confíe en él. Satoshi Nakamoto y Vitalik Buterin han probado Bitcoin y ETH, y EOS aún necesita que BM (Daniel Larimer) continúe trabajando duro. BM acaba de responder que EOSIO es un gran producto, y EOS es una comunidad tan grande como las personas que eligen unirse a ella. EOSIO puede completar todas las funciones en ETH y el producto es muy bueno. No se puede pedir una comunidad descentralizada y pedirle a alguien que se encargue de construirla, eso es responsabilidad de todos. [2020/9/24] 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). Voz | EOS42: La cooperación con los reguladores ayuda a la adopción de blockchain: el nodo EOS EOS42 tuiteó hoy que, en muchos casos, las personas adoptarán blockchain porque trabajan directamente con los reguladores para remodelar el planeta Ideas futuras para la educación, la colaboración y la ejecución. [2019/12/14] Aparentemente, este diseño heredado 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. 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. La frecuencia de búsquedas de palabras clave negativas para Bitcoin ha aumentado; el lanzamiento de la red principal EOS se ha convertido en un punto caliente hoy: según los datos de TokenInsight, el índice TI, que refleja el desempeño general de la industria de la cadena de bloques, reportó 1054.06 puntos el día 9 de la octava hora de Beijing, por debajo de 8,15 puntos respecto al mismo período de ayer, una caída del 0,77 %. El índice general de plataforma TIG reportó 1121.87 puntos, 2.05 puntos o 0.18% menos que en el mismo período de ayer. Según el monitoreo, el número de transferencias de BTC disminuyó un 2,4% respecto al mismo período de la semana pasada a 208.000. La tasa de crecimiento de la actividad comunitaria se mantuvo estable en 0,1% (0,09% el mes pasado), con un crecimiento lento y de baja velocidad durante 90 días consecutivos. La frecuencia de búsqueda de palabras clave negativas como "muerte de bitcoin" y "estafa de bitcoin" aumentó. Los analistas de BCtrend creen que cuando las creencias están dispersas, es hora de recolectar fichas baratas. Aunque la tendencia actual del mercado es débil, se ha revelado la situación actual de que hay más vendedores en corto que vendedores en corto, y las posiciones cortas de futuros han superado repetidamente más del 60% de las posiciones totales, pero todavía no hay resultado. El sentimiento del mercado se recuperó lentamente en junio. El analista Bi Dongxie cree que el lanzamiento de la red principal de EOS se ha convertido en un tema candente en la actualidad, y se espera que EOS enfrente muchos problemas después de que se conecte en el futuro, lo que no aumentará el precio. BTC ha estado operando lateralmente desde junio, y las fluctuaciones se han vuelto cada vez más pequeñas. Se recomienda que los inversores continúen manteniendo los fondos y esperen hasta que el mercado esté completamente despejado antes de operar. [2018/6/8] Suponiendo que el registro de auditoría no haya sido manipulado, el auditor deberá 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. El código de prelanzamiento de EOSIO Dawn 3.0 se ha abierto en GitHub: según Cointelegraph, el código de prelanzamiento de EOSIO Dawn 3.0 (prelanzamiento) se ha subido a GitHub para código abierto. Se informa que la versión oficial de Dawn 3.0 se lanzará en junio, lo que BM llama "un hito importante que conduce a la primera versión de EOSIO". Dawn 2.0 se lanzó en diciembre del año pasado. [2018/4/7] La ​​verdad es que escribir código determinista es un desafío para los mejores desarrolladores, entrenados en trampas 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 fabricado con tecnología de bajo nivel, también podemos diseñar los transistores de mejor rendimiento.

Tags：

Ethereum