BM: ¿Por qué blockchain es una mejor arquitectura de servidor de aplicaciones/base de datos?

(Night, Van Gogh) Prólogo: Existen problemas de seguridad en la arquitectura tradicional de aplicaciones web. Para garantizar un mayor nivel de seguridad, las empresas han gastado enormes sumas de dinero, pero aún no pueden resolver el problema de manera fundamental. El autor de este artículo, Daniel Larimer (también conocido como el BM de EOS), cree que para resolver este problema, es necesario adoptar una arquitectura de cadena de bloques para garantizar la seguridad de las bases de datos y las cuentas de los usuarios, lo que puede evitar el acceso no autorizado y la manipulación. -prueba, y puede Ahorros para las empresas que adoptan la tecnología blockchain. BM cree que blockchain es una mejor arquitectura de base de datos/servidor de aplicaciones, y se convertirá en una tecnología imprescindible para muchas empresas en el futuro.¿Será este un gran mercado potencial? ¿Qué piensas? Este artículo fue traducido por la comunidad "DoTi" de Blue Fox Notes. Las infraestructuras de aplicaciones web tradicionales se diseñaron teniendo en cuenta la seguridad y, durante veinticinco años, las empresas han intentado reparar arquitecturas fundamentalmente inseguras. El diseño arquitectónico asume que los servidores son confiables y están protegidos, pero años de experiencia nos dicen que ningún servidor está a salvo de ataques externos, y mucho menos de peligros internos. En otras palabras, el servidor está fundamentalmente centralizado. Solíamos atribuir el "problema de seguridad" a la conexión entre el usuario y el servidor, por lo que introdujimos SSL y HTTPS. Sin embargo, más tarde descubrimos que los piratas informáticos comprometían la base de datos y robaban las contraseñas. Entonces comenzamos a almacenar hashes de contraseñas, pero luego descubrimos que después de robar los hashes, los piratas informáticos podían usar la fuerza bruta para descifrar las contraseñas. Luego introdujimos la rotación de contraseñas para que cuando un hacker fuerza bruta, la contraseña cambie. Tales y tales ataques y defensas se organizan constantemente. (Notas de Blue Fox: SSL es un protocolo que brinda seguridad para las comunicaciones de red. El protocolo SSL se encuentra entre el protocolo TCP/IP y el protocolo de capa de aplicación, y cifra las conexiones de red. HTTPS agrega SSL a HTTP). BM: B1 se iniciará el código del grupo de compromiso en las próximas semanas para buscar comentarios de la comunidad: el 18 de marzo, algunos usuarios de Twitter tuitearon que, dado que BM regresa al gobierno de EOS, confían nuevamente en EOS y le preguntaron a BM sobre el plan DeFi de EOS y el cronograma del grupo de participación. BM respondió que B1 debería proponer códigos y sistemas en las próximas semanas para recibir comentarios de la comunidad. Lo sé pronto. Anteriormente, el 13 de marzo, el fundador de EOS, BM, presentó un borrador de propuesta para la gobernanza comunitaria de EOS. El borrador describe un proceso para investigar y designar personas para controlar la distribución de tokens EOS. [2021/3/18 18:55:41] Las empresas gastan miles de millones de dólares tratando de proteger sus servidores y bases de datos y, a pesar de estos esfuerzos, todavía no hay una manera fácil de auditar los sistemas y garantizar que las empresas funcionen como quieren. Block.one está creando un software de cadena de bloques para proteger las bases de datos y las cuentas de usuario del acceso no autorizado y la modificación no contabilizada. Al usar blockchain, los usuarios emplean claves privadas de alta seguridad que se almacenan en hardware seguro y se utilizan para firmar cada interacción del usuario, en lugar de simplemente verificar una conexión a un servidor. (Nota de Blue Fox: Block.one es la empresa que desarrolla el software EOSIO) La cadena de bloques crea un registro inmutable, que crea un orden absoluto y determinista, recibe información del usuario y los contratos inteligentes proporcionan una lógica empresarial determinista para garantizar la consistencia del sistema. Block.one del futuro está creando formas de eliminar contraseñas y auditorías costosas, ahorrando a las empresas miles de millones de dólares, evitando el robo de identidad y brindando una mayor confiabilidad y auditabilidad para todos. Ha sido mi firme creencia durante muchos años que cada sitio web multiusuario puede beneficiarse de tener un backend de blockchain. Contrariamente a la creencia popular, las cadenas de bloques no tienen por qué ser bases de datos lentas e ineficientes, ni necesariamente operan sobre una base de acceso abierto y resistente a la censura. BM: EOS es más simple que ETH en términos de lenguaje personalizado: el fundador de EOS, Daniel Larimer (BM), acaba de twittear que el lenguaje personalizado de ETH, el modelo de almacenamiento limitado y el lento proceso de actualización lo hacen extremadamente complicado. Por el contrario, EOS es muy simple. [2020/8/16] Incluso si la cadena de bloques es completamente operada por la propia empresa, y todo el contenido de la cadena de bloques no es público, la cadena de bloques puede proporcionar un gran beneficio para la empresa en términos de seguridad, auditabilidad, transparencia y integridad de los procesos de negocio. Este artículo tiene como objetivo arrojar luz sobre el verdadero valor de blockchain en un entorno empresarial y señalar el camino a seguir para la industria de blockchain. Un concepto erróneo común en la industria de las cadenas de bloques es que las cadenas de bloques solo pueden brindar beneficios cuando conectan partes que no confían entre sí. Creen que la tecnología de base de datos tradicional ya puede hacer todo lo necesario para garantizar la integridad empresarial. 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 no comprenden las garantías de seguridad e integridad fundamentalmente diferentes que brindan las cadenas de bloques: Compromiso con el orden del tiempo global Ejecución determinista de la lógica comercial Estrecho acoplamiento de la lógica comercial y la integridad de los datos En la arquitectura de aplicaciones comerciales de, el negocio la lógica 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 autentica al usuario, emite un token de sesión, que se utiliza para autenticar futuras interacciones del usuario, hasta que se agote el tiempo de la sesión 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. El servidor de aplicaciones es responsable de hacer cumplir su propio esquema de autenticación con el uso final final. Además, obviamente, suele haber varias partes con acceso a nombres de usuario y contraseñas. Los administradores de bases de datos pueden asignar y revocar credenciales a muchos servidores de aplicaciones y/o personas diferentes. Voz | BM: EOS Authenticator es solo un LastPass más seguro: según los informes de IMEOS, BM alentó las discusiones con la comunidad en el grupo de Telegram. Los miembros de la comunidad discutían que la versión IOS de muchas billeteras ha eliminado muchas DApps, e incluso la entrada del navegador DApp está bloqueado, no queda ninguno. BM respondió: EOS Authenticator es seguro porque no tiene un navegador integrado, que es la base de su diseño. EOS Authenticator es solo una versión más segura de LastPass. [2019/7/19] Los sistemas avanzados aseguran que cada servidor de aplicaciones tenga su propio nombre de usuario/contraseña en un sistema de escala horizontal y, en algunos casos, incluso puede usar infraestructura de clave pública (PKI) y módulos de seguridad de hardware (HSM). Sin embargo, incluso aquí, la base de datos solo autentica la conexión con el servidor de aplicaciones. Para proporcionar registros de auditoría, debe registrar todo el flujo de datos de una conexión segura. Sin embargo, aunque este registro solo registra "lecturas y escrituras" solicitadas por el servidor de aplicaciones, el servidor de aplicaciones ha perdido toda la información sobre la intención original del usuario. Un auditor que revisa un sistema de este tipo no tiene forma de saber si el servidor de aplicaciones (como Node.js) está siguiendo la lógica empresarial correcta y autenticando correctamente al usuario final. El proceso de Node.js puede "registrar" las operaciones del usuario en la base de datos, de modo que los auditores puedan intentar reproducir el mismo cálculo, pero este registro en sí no es a prueba de manipulaciones, no viene con una autenticación verificable independiente y no puede verificar el final. usuario Si la operación que registra está realmente autorizada. Se podría intentar registrar las conexiones de cada usuario, pero dado que los usuarios a menudo transmiten contraseñas a través de dichas conexiones, estos registros terminan creando trampas que pueden provocar la filtración de las credenciales de los usuarios. (Nota de Blue Fox: Honeypot significa un lugar rico que a los piratas informáticos les gusta atacar) Un sistema más responsable puede cifrar estos registros para que solo los auditores puedan leerlos. Voz | BM: vota automáticamente de acuerdo con las preferencias de votación de los usuarios a través de algoritmos y optimiza el mecanismo de votación: según las noticias de Whale Exchange, BM apareció hoy en el grupo de Telegram y tuvo una acalorada discusión con miembros de la comunidad sobre temas de votación. un resumen del contenido importante: 1. BM dijo, hoy tengo algunas ideas geniales para mejorar el mecanismo de votación. Este es básicamente un algoritmo que automatiza de manera efectiva la votación en función de las preferencias de votación del usuario. Supongamos que desea votar por un BP que tiene más votos de los necesarios, sus votos se pueden transferir automáticamente para apoyar al próximo BP que cumpla con sus preferencias. 2. En este sentido, algunos miembros de la comunidad no están de acuerdo con esta idea. BM dijo que si desea mantener la diversidad de BP, ¿votará por el nodo oriental o el nodo occidental? Algunas personas solo votarán por el nodo oriental. De acuerdo con el algoritmo mencionado anteriormente, puede votar de acuerdo con su preferencia personal, y el algoritmo admitirá primero el nodo occidental hasta que los dos votos alcancen un equilibrio. 3. Más tarde, algunos miembros de la comunidad dijeron: Me gusta mucho esta idea, ¿utilizará el mecanismo de 1 moneda, 1 voto o el sistema actual? BM dijo, mecanismo de 1 moneda 1 voto. 4. El objetivo de la descentralización es evitar los ataques del 51 %, por lo que el 51 % no debería tener el control. [2019/6/25] Suponiendo que el registro de auditoría no haya sido manipulado, el auditor debe ejecutar la misma secuencia de operaciones a través de la lógica de la aplicación para verificar que el estado de la base de datos resultante coincida. Esto significa que los servidores de aplicaciones deben implementarse de manera determinista. La computación determinista no es fácil Aunque escribir código determinista puede parecer "fácil", de hecho, todos los lenguajes informáticos de propósito general son no deterministas porque permiten a los desarrolladores acceder a datos externos almacenados en bases de datos. Esto podría ser algo tan simple como una marca de tiempo, una dirección de memoria, una variable de entorno, una dirección IP u otros datos más sutiles, como el comportamiento del punto flotante en el hardware o el orden de inserción de una tabla hash. En muchos casos, simplemente acceder a las variables en la memoria de un servidor de aplicaciones de ejecución prolongada es suficiente para introducir el no determinismo. La operación real de iniciar/detener el servidor de aplicaciones debe grabarse y reproducirse; de ​​lo contrario, cada acceso a la memoria local puede no ser determinista durante la reproducción. Voz | BM: EOS se puede retener y transferir sin una cuenta: según los informes de IMEOS, BM envió el artículo de Everipedia "El nuevo contrato inteligente permite a los titulares de EOS transferir tokens sin una cuenta de EOS" en Twitter y escribió "EOS ahora se puede retener y transferido sin una cuenta. Me alegra ver que la comunidad hace que EOS sea más accesible". El artículo de Everipedia presenta el modelo de contrato EOSIO UXTO (también conocido como Pay2Key). El contrato permite que los tokens se envíen solo entre claves públicas de EOS, por lo que los tokens se pueden retener y transferir sin una cuenta de EOS. [2019/5/2] La verdad es que escribir código determinista es un desafío para los mejores desarrolladores capacitados en las trampas comunes y que buscan activamente el no determinismo. A un desarrollador típico de aplicaciones comerciales le resultará difícil o poco práctico escribir código de manera determinista. Si vamos más allá y asumimos que el código de la aplicación es determinista, de modo que las aplicaciones registran fielmente los eventos de los usuarios, aún enfrentamos el desafío de rastrear qué versión del código se implementó en un momento dado. 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. Después de eso, los auditores necesitan copias de todas las versiones del código del servidor de aplicaciones y deben reproducir la entrada del usuario en cada actualización de versión (y reiniciar el código en cada reinicio en el pasado). Incluso si un solo servidor de aplicaciones pudiera operar de manera determinista en términos de su implementación y despliegue, aún enfrentaría problemas de escalabilidad significativos. Solo se puede ejecutar una instancia del servidor de aplicaciones en la base de datos. El acceso paralelo se logra a través de bloqueos complejos, pero incluso las condiciones de carrera en los bloqueos deben documentarse y reproducirse, de lo contrario, dos instancias de lógica de aplicación con diferentes variables locales pueden producir resultados no deterministas. En este punto, se podría tratar de desechar el determinismo por completo, pero sin el determinismo, las pequeñas variaciones pueden acumularse con el tiempo y eventualmente dar lugar a grandes variaciones en los conjuntos de datos. Los auditores se verán obligados a utilizar la lógica difusa y la coincidencia aproximada, y todos tendrán que confiar en que esta "lógica difusa" es lo suficientemente buena. Por supuesto, la única forma de anular todo el esfuerzo de escribir e implementar código determinista es si el DBA modifica el código directamente y sin que nadie lo note. En algunos casos, la actualización cuidadosa de los registros de entrada del usuario y el estado puede crear dos estados de base de datos diferentes, cada uno de los cuales pasa las pruebas deterministas, pero aún tiene salidas diferentes e irreconciliables. Por ejemplo, suponga que un profesor envía la calificación F de un estudiante al sistema, y ​​el estudiante luego piratea o soborna en la base de datos y cambia su calificación, así como el registro de la presentación del profesor. Reemplazo de contraseñas El objetivo final de cualquier sistema multiusuario que se preocupa por la integridad es garantizar que la entrada del usuario no se pueda falsificar. El uso de nombre de usuario/contraseña, o incluso otra autenticación de múltiples factores como SMS o Google 2FA, depende de que el servidor llegue a la conclusión de que las contraseñas coinciden o que se ingresó el código SMS/enlace de correo electrónico/código 2FA correcto. Obviamente, este es un gran problema para la integridad del sistema, y ​​proporcionaré un ejemplo del mundo real de cuán serios son estos sistemas. En 2016, piratearon mi cuenta en un intercambio de criptomonedas, lo que permitió a los piratas robar decenas de miles de dólares en Bitcoin. Desde mi perspectiva, el truco primero mostró un correo electrónico de "restablecimiento de contraseña" enviado a mi correo electrónico, y luego otro correo electrónico que mostraba que la contraseña se había restablecido con éxito. Posteriormente, se recibió un correo electrónico solicitando confirmación para retirar bitcoins (código/enlace adjunto). Finalmente, recibí una notificación de que el retiro se ha completado. A primera vista, parecía que el correo electrónico había sido pirateado, pero dado que tenía un inicio de sesión de múltiples factores en mi correo electrónico, era poco probable que hubiera sido pirateado. Un vistazo rápido a la página de seguridad de mi correo electrónico muestra que no hay acceso no autorizado. Lo sé porque Google registra y muestra todas las IP/dispositivos que acceden a mi correo electrónico. Y lo que sucedió aquí fue que el atacante interceptó el correo electrónico del intercambio incluso antes de que llegara a mi buzón. El servidor de aplicaciones no tiene forma de saber que el correo ha sido interceptado, por lo que solo se basa en que el atacante tenga el código único generado por el servidor de aplicaciones para realizar la autorización de restablecimiento y retiro de contraseña. La orientación por SMS o cualquier otra tecnología que dependa de claves privadas no controladas por el usuario podría explotarse de la misma manera

Tags：

Precio de Bitcoin