Patrones de diseño y seguridad de la arquitectura backend de Dapp

Las aplicaciones descentralizadas (DApps) requieren un diseño de sistema especial para lograr una alta seguridad y confiabilidad. En este artículo, utilizaré Ethereum como ejemplo principal para presentar varios principios fundamentales sobre cómo diseñar e implementar correctamente backends y contratos inteligentes para aplicaciones descentralizadas, aunque la mayoría de ellos se aplicarán a Eos, Tron y otras plataformas de datos descentralizadas. Enfoque del artículo: cómo almacenar claves privadas en el backend sin tener en cuenta la seguridad Cómo diseñar correctamente contratos inteligentes y contenido "descentralizado" Ejemplos de arquitectura de aplicaciones descentralizadas y semidescentralizadas Cómo lidiar con la carga y fallas de la red y otras preguntas de bajo nivel Comencemos ! A pesar de las muchas dificultades regulatorias y de adopción que enfrenta hoy en día, blockchain es una tecnología que vivirá para siempre, independientemente del algoritmo, ya sea blockchain, hashgraph, speed o cualquier otra tecnología de registro distribuido. El principal valor aportado por blockchain y otras tecnologías similares se puede resumir de la siguiente manera: permiten a las personas escribir y ejecutar programas que no se pueden cambiar en la práctica después de su creación, ni manipularse durante la ejecución. En otras palabras, estos programas siempre funcionan según lo diseñado y ninguna parte puede influir en su comportamiento. Esta definición es válida para muchas criptomonedas que existen hoy en día, si las consideramos como programas que definen cómo se transfieren las monedas de un lado a otro. Esto también explica por qué las criptomonedas y los tokens múltiples tienen un valor real: no se pueden crear de la nada mediante "procedimientos subyacentes" definidos. A diferencia de Bitcoin, la plataforma Ethereum/EOS/Tron/… implementa una capa de programación más compleja, que a su vez implementa el entorno de ejecución, lo que permite que cualquier persona escriba sus propios programas descentralizados sobre la plataforma. Los programas definidos por el usuario siempre se ejecutan según lo diseñado sin anomalías, y su seguridad está garantizada por la plataforma. Estos programas seguros e inmutables que se ejecutan en una red descentralizada combinados con tecnologías front-end y back-end tradicionales se conocen hoy como aplicaciones descentralizadas (ÐApps). Si bien parte de esto puede estar semicentralizado, la mayor parte de la actividad en una aplicación verdaderamente descentralizada debe realizarse bajo control central. Si alguien me pidiera que dibujara cómo funcionan las DApps hoy en día, probablemente dibujaría esta imagen. Imagine lo que hoy llamamos una aplicación descentralizada, tome cualquier recurso web centralizado existente como _YouTube_ o _Instagram_ como ejemplo, e imagine vincular su "identidad criptográfica" a una recurso web/móvil, en lugar de una cuenta centralizada protegida con contraseña. Esto es lo que le ofrece el software de billetera electrónica. La clave privada de la identidad (el secreto en cuyo nombre puede actuar) se almacena localmente en su dispositivo y nunca se conecta, por lo que nadie puede controlar esta identidad. Con esta identidad, puede realizar diferentes operaciones en la red tanto centralizada como descentralizada (que es una red diferente de la WWW tradicional, donde el objetivo es eliminar la autoridad central) (donde una autoridad central controla los recursos de la red) y convertir sitios web en un punto de acceso y/o una interfaz gráfica de usuario. El objetivo de esta "identidad criptográfica" es que sus acciones están protegidas criptográficamente y nadie puede cambiar lo que firma o lo que firma. Hoy en día, las redes descentralizadas tolerantes a fallas como Ethereum, EOS o Tron están limitadas en sus capacidades informáticas y de almacenamiento. Si son escalables, podemos usar redes descentralizadas para almacenar aplicaciones descentralizadas completas, incluida su GUI, datos y lógica comercial. En este caso, nos referimos a estas aplicaciones como aplicaciones verdaderamente descentralizadas/distribuidas. Sin embargo, dado que estas redes actualmente no son escalables, combinamos diferentes enfoques para lograr el máximo nivel de descentralización para nuestra aplicación. Como sabemos, no hay desarrollo en el backend "tradicional". Por ejemplo: Tres organizaciones de las Naciones Unidas adoptan la solución de votación electrónica basada en Tezos Electis: Según las noticias del 30 de julio, en una declaración reciente, tres organizaciones de las Naciones Unidas han adoptado recientemente la solución de votación electrónica basada en Tezos Electis, a saber, la CMNUCC ( CMNUCC), la la organización constituyente oficial de niños y jóvenes YOUNGO, el SDG7 Youth Constituency, una organización que tiene como objetivo dar a la juventud global una voz en el sector energético, y el Women and Gender Constituency (WGC). La adopción de Electis por parte de estas organizaciones de las Naciones Unidas es una señal más del creciente número de instituciones que confían en blockchain. (The Crypto Basic) [2022/7/30 2:47:46] Usamos el backend para alojar el frontend de la aplicación descentralizada. Usamos el backend para integrarlo con cualquier otra tecnología y servicio existente. Una aplicación verdaderamente de clase mundial no puede vivir aislada. Usamos backends para almacenar y procesar cualquier cosa que sea lo suficientemente decente para descentralizar una red, especialmente una cadena de bloques. De hecho, toda la aplicación y su lógica comercial se almacenan en algún lugar del mundo, sin incluir la parte de la cadena de bloques. Sin mencionar que IPFS y capas de almacenamiento similares no garantizan la accesibilidad de los archivos, por lo que no podemos confiar en ellos sin alojar los archivos nosotros mismos. En otras palabras, siempre se requiere un servidor en ejecución dedicado. Hasta ahora, era imposible crear aplicaciones seguras y parcialmente descentralizadas sin usar un backend confiable, y el objetivo de este artículo es explicar cómo hacerlo correctamente. Da la casualidad de que casi todas las aplicaciones descentralizadas de la actualidad se basan en los llamados tokens, que son criptomonedas que impulsan aplicaciones descentralizadas específicas personalizadas (o simplemente clonadas). Un token es simplemente una moneda o activo programable, nada más. El contrato inteligente de fichas determina cómo los usuarios transfieren fichas, mientras que el contrato inteligente de aplicaciones puede ampliar todo lo que falta en el contrato inteligente de fichas. Ambos tipos de contratos inteligentes se ejecutan sobre una red descentralizada. Por lo general, los tokens son "contratos inteligentes" escritos sobre una plataforma descentralizada como Ethereum. Al poseer algunos tokens, básicamente puede obtener diferentes servicios en recursos web o aplicaciones móviles e intercambiar ese token por otra cosa. El punto clave aquí es que el token en sí existe y no está controlado por una autoridad central. Hay muchos ejemplos de aplicaciones basadas en tokens: desde numerosos juegos coleccionables como CryptoKitties (tokens ERC721) hasta aplicaciones orientadas a servicios como LOOM Network, e incluso navegadores como Brave y DreamTeam (tokens compatibles con ERC20) como plataformas de juego. . Depende de los propios desarrolladores determinar y decidir cuánto control tendrán (o no) sobre sus aplicaciones. Pueden construir la lógica comercial de toda la aplicación sobre contratos inteligentes (como lo hizo CryptoKitties), o no usan contratos inteligentes en absoluto y centralizan todo en el servidor. Sin embargo, la mejor manera es centrarlo. Desde un punto de vista técnico, debe haber un puente que conecte tokens y otros contratos inteligentes con aplicaciones web/móviles. En las aplicaciones totalmente descentralizadas de hoy en día, donde los clientes interactúan directamente con los contratos inteligentes, este puente se reduce a una API pública o una función API JSON RPC de un grupo de nodos como Infura, ya que no todos los dispositivos pueden ejecutar y admitir sus nodos de red individuales. Sin embargo, esta API proporciona solo un conjunto básico y muy limitado de funciones que solo permiten consultas simples o una agregación eficiente de datos. Entonces, finalmente, se introduce un backend personalizado, lo que hace que la aplicación sea semicentralizada. Toda la interacción con la red descentralizada se puede acotar a uno o dos puntos, según las necesidades de la aplicación: LBank Blue Shell lanzó MATIC a las 20:00 horas del 27 de mayo: Según el anuncio oficial, a las 20:00 horas del 27 de mayo El 27 de febrero, LBank Blue Shell (LBank.me) lanzó MATIC (Polygon) y lanzó operaciones en red al mismo tiempo, abriendo operaciones en USDT, abriendo depósitos a las 16:00 el 27 de mayo y abriendo retiros a las 16:00 el 29 de mayo. Según los datos, MaticNetwork ahora pasa a llamarse Polygon. MaticNetwork es una plataforma de escalabilidad de segunda capa que permite transacciones fuera de la cadena rápidas, simples y seguras, no solo para transacciones de pago, sino también para contratos inteligentes fuera de la cadena generalizados. [2021/5/27 22:49:27] Escuche los eventos de la red (por ejemplo, transferencias de tokens) / lea el estado de la red. Publicar transacciones (funciones de contratos inteligentes que cambian el estado de las llamadas, como transferencias de tokens). Ambos aspectos son difíciles de implementar, especialmente si queremos construir una solución de back-end segura y confiable. Estos son los puntos principales que queremos desglosar: Primero, en Ethereum, la recuperación de eventos no es compatible de forma inmediata. Por muchas razones: los nodos de la red pueden fallar al extraer una gran cantidad de eventos, los eventos pueden desaparecer o cambiar debido a la bifurcación de la red, etc. Tuvimos que construir una capa de abstracción para sincronizar eventos en la red y garantizar su entrega confiable. Al igual que la publicación de transacciones, tuvimos que abstraer las cosas de gama baja de Ethereum, como los contadores de nonce y las estimaciones de gas, así como la republicación de transacciones, para proporcionar una interfaz confiable y estable. Además, la publicación transaccional implica el uso de claves privadas, lo que requiere seguridad de back-end avanzada. Seguridad. Lo tomaremos en serio y enfrentaremos el hecho de que no hay garantía de que las claves privadas nunca se vean comprometidas en el back-end. Afortunadamente, hay una manera de diseñar aplicaciones descentralizadas que ni siquiera requieren cuentas back-end altamente seguras. En nuestra práctica, todo esto nos llevó a crear una poderosa solución de back-end para Ethereum, a la que llamamos Ethereum Gateway. Abstrae la diversión de Ethereum de otros microservicios y proporciona una API sólida para consumirla. Monitoreo de back-end para Ethereum. La actividad que muestra el monitor está relacionada principalmente con nuestra función de facturación recurrente (aunque puede ver picos por hora). Esta parte depende en gran medida de las necesidades de aplicaciones descentralizadas específicas. Intentaremos resolver algunos patrones de interacción básicos sobre la base de la creación de estas aplicaciones (Ð plataforma = plataforma descentralizada = Ethereum / EOS / Tron / Lo que sea): Cliente ⬌ Plataforma: Aplicación totalmente descentralizada. Los clientes (navegadores o aplicaciones móviles) se comunican directamente con la plataforma descentralizada con la ayuda del software de "billetera" Ethereum (como Metamask, Trust) o billeteras de hardware (como Trezor o Ledger). Los ejemplos de DApps creados de esta manera incluyen CryptoKitties, Loom's Delegated Call, las billeteras criptográficas (Metamask, Trust, Tron Wallet, etc.), intercambios criptográficos descentralizados (como Etherdelta), etc. D-Platform ⬌Client ⬌Backend ⬌D-Platform: Aplicación centralizada o semicentralizada. Los clientes interactúan con plataformas y servidores descentralizados con poco en común. Un buen ejemplo es cualquier intercambio de criptomonedas (centralizado) hoy en día, como BitFinex o Poloniex: las monedas que negocia en el intercambio solo se registran en las bases de datos tradicionales. Puede "recargar" el saldo de su base de datos enviando activos a una dirección específica ("plataforma ⬌cliente"), y luego retirar sus activos después de realizar ciertas acciones en la aplicación (fondo ⬌Ðplataforma), sin embargo, todo lo que haga todo depende en la "aplicación" en sí (cliente ⬌backend) no significa que interactúe directamente con la plataforma Ð. Otro ejemplo es Etherscan.io, que utiliza un enfoque semicentralizado: puede realizar todas las operaciones descentralizadas útiles allí, pero la aplicación en sí misma no tiene sentido sin su backend integral (Etherscan sigue sincronizando transacciones, analizando datos y almacenándolos, y finalmente proporciona una API/UI completa). Algo intermedio: aplicaciones estáticas, centralizadas o semicentralizadas. Combina los métodos anteriores. Por ejemplo, podríamos tener una aplicación que brinde varios servicios a cambio de encriptación, permitiéndole iniciar sesión y firmar información usando una identidad encriptada. Con suerte, el modo de interacción de una aplicación completamente descentralizada (plataforma cliente) no causará ningún problema. Con servicios asombrosos como Infura o Trongrid, simplemente puede crear aplicaciones que no requieren un servidor en absoluto. Como casi cualquier biblioteca cliente como Ethers.js para Ethereum o Tron Web para Tron, puede conectarse a estos servicios públicos y comunicarse con la red. Sin embargo, para consultas y tareas más complejas, es posible que deba asignar su propio servidor. El resto de los patrones de interacción que involucran al backend hacen que las cosas sean más interesantes y complejas. Para visualizar todo esto, imaginemos una situación en la que el backend reacciona a ciertos eventos en la red. Por ejemplo, un usuario publica una transacción de cuota que nos permite cobrarle una tarifa. Para cobrar una tarifa, tenemos que publicar una transacción de tarifa para el evento de cuota que se emite: Ejemplo de flujo de reacción del servidor a la acción del usuario en una red descentralizada Desde una perspectiva de back-end, sucede lo siguiente: escuchamos una red específica sondeando constantemente el evento de la red. Después de recibir el evento, realizaremos alguna lógica comercial y luego decidiremos emitir una transacción en respuesta. Antes de publicar una transacción, queremos asegurarnos de que se pueda minar (en Ethereum, una estimación de gas de transacción exitosa significa que no hay errores en relación con el estado actual de la red). Sin embargo, no podemos garantizar que las transacciones se extraerán con éxito. Usando la clave privada, firmamos y publicamos la transacción. En Ethereum, también tenemos que determinar el precio del gas y el límite de gas para la transacción. Después de que se publica una transacción, sondeamos continuamente la red para conocer su estado. Si tarda demasiado y no obtenemos el estado de la transacción, tenemos que volver a publicarla o desencadenar una "condición de error". Las transacciones se pueden perder por varias razones: congestión de la red, caídas de pares, aumento de la carga de la red, etc. En Ethereum, también puede considerar volver a firmar la transacción con un precio de gas (real) diferente. Después de finalizar las transacciones, podemos realizar más lógica comercial si es necesario. Por ejemplo, podemos notificar a otros servicios de back-end sobre el hecho de que se completó una transacción. Además, considere esperar varias confirmaciones antes de tomar una decisión final sobre una transacción: la red está distribuida, por lo que los resultados pueden cambiar en segundos. Como puedes ver, ¡pasaron muchas cosas! Sin embargo, es posible que su aplicación no requiera algunos de estos pasos, según lo que intente lograr. Sin embargo, construir un backend robusto y estable requiere abordar todos los problemas anteriores. Vamos a desglosarlo. Aquí quiero resaltar algunos puntos donde surgen la mayoría de los problemas, a saber: Escuchar eventos de red y leer datos de la red Publicar transacciones y cómo realizar transacciones de manera segura En Ethereum, así como en otras redes descentralizadas, eventos de contrato inteligente (o registro de eventos , o simplemente un registro) permite que las aplicaciones fuera de la cadena entiendan lo que sucede en la cadena de bloques

Tags：

Binance Download