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. (Nota 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 sobre la base de HTTP). 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 se espera. 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. Datos: El TVL de Ethereum Bridge alcanzó los 14,77 mil millones de dólares estadounidenses: Jinse Finance informó que los datos de Dune Analytics mostraron que el TVL actual de Ethereum Bridge alcanzó los 14,77 mil millones de dólares estadounidenses. Entre ellos, los cinco puentes con el volumen de bloqueo más alto son Polygon Bridges ($ 4,434 mil millones), Fantom Anyswap Bridge ($ 3,787 mil millones), Avalanche Bridge ($ 3,734 mil millones), Arbitrum Bridges ($ 2,092 mil millones), Optimism Bridges ($ 260 millones) ) . [2021/10/13 20:26:21] 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 también puede proporcionar seguridad, auditabilidad, transparencia y procesos comerciales para el compañía Proporciona una gran mejora en la integridad. 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 a 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. Los sistemas avanzados aseguran que cada servidor de aplicaciones tenga su propio nombre de usuario/contraseña en un sistema escalado horizontalmente 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. Esta semana, se desbloquearán 6,7231 millones de DOT. La semana pasada se comprometieron un total de 5,4349 millones de DOT: según los datos de Subscan, el número total de DOT publicados por Polkadot esta semana (del 1 de marzo al 7 de marzo) es de 6,7231 millones de DOT, y el el valor máximo de la eliminación de apuestas está en El 4 de marzo, se eliminaron un total de 2 196 400 DOT. La semana pasada (2,22-2,28) se comprometieron un total de 5,4349 millones de DOT, y la tasa hipotecaria DOT actual de la red de Polkadot es del 64,9 %. [2021/3/1 18:03:01] 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 comercial 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. 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. La verdad es que escribir código determinista es un desafío para los mejores desarrolladores que están capacitados en las trampas comunes y 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. Lo mismo podría explotarse potencialmente contra SMS o cualquier otra tecnología que se base en claves privadas no controladas por el usuario. Al final del día, la única forma de mantener seguras las cuentas de los usuarios es que todos los usuarios usen claves privadas basadas en hardware como sus credenciales de inicio de sesión, combinadas con un proceso sólido y lento para restablecer de forma segura la clave de hardware si se pierde. . En este punto, la aplicación comercial multiusuario ahora puede firmar cada solicitud de usuario con la clave privada del usuario, registrar esa solicitud firmada en la base de datos y procesarla usando un código determinista. Incluso esto no proporciona la integridad que uno esperaría, ya que toda la solicitud del usuario aún se puede eliminar con efectos secundarios. Imagínese piratear la base de datos de la policía y eliminar las solicitudes firmadas por la policía al enviar las multas de los usuarios. Habiendo dicho eso, los ingenieros expertos afirmarán que cada problema que planteo se puede resolver cambiando la lógica del programa. Tiene razón en que los desarrolladores de aplicaciones experimentados pueden usar "bases de datos tradicionales", "servidores de aplicaciones tradicionales" y "primitivas criptográficas comunes" y construir sistemas relativamente seguros y auditables. Por la misma lógica, un ingeniero experto podría afirmar que una base de datos es completamente innecesaria y, en cambio, todo debería construirse directamente en el sistema de archivos. Y otros ingenieros pueden señalar que el rendimiento se puede mejorar escribiendo todo el código desde cero, en lugar de depender de marcos de servidores de aplicaciones como Node.js y J2EE. Casi todo está construido a partir de tecnologías de bajo nivel, y también podríamos diseñar transistores para un rendimiento óptimo. (Nota de Blue Fox: esto significa que el costo de estas soluciones es extremadamente alto) Hago esta sugerencia extrema porque destaca el papel real de los marcos de trabajo de nivel superior para acelerar y garantizar el desarrollo de nuevas aplicaciones. Pocas personas escriben sus propias bibliotecas de criptografía o algoritmos, y los que lo hacen son expertos o sirven como guardianes cuando se piratean los sistemas. Desarrollar/refactorizar todo desde cero da como resultado un costo por aplicación más alto que uno creado en un marco maduro. Beneficios del servidor de base de datos/aplicación de cadena de bloques Las cadenas de bloques y los marcos de desarrollo como EOSIO existen para liberar a los desarrolladores de aplicaciones de tener que reinventar "bases de datos" para crear aplicaciones seguras. La seguridad y el determinismo son difíciles, por lo que la tecnología se basa en capas que abstraen los detalles. EOSIO combina un entorno de ejecución determinista (WebAssembly) y una base de datos rápida en un mismo proceso. Todas las operaciones de los usuarios están firmadas por sus claves privadas y registradas en una base de datos distribuida replicada, con la capacidad de realizar compromisos públicos para bloquear encabezados. Es solo cuestión de tiempo antes de que un marco como EOSIO sea tan poderoso y fácil de desarrollar como un sistema tradicional.

Tags：

USDT