Curso de Blockchain (22). Escalabilidad y otros desafios

Este post tiene como objetivo explorar varios desafíos que deben abordarse antes de que blockchain pueda convertirse en una tecnología convencional. A pesar del hecho de que se han desarrollado múltiples casos de uso y pruebas de concepto (PoC) , y que la tecnología funciona bien para muchos escenarios, todavía existe la necesidad de abordar algunas limitaciones fundamentales que están presentes en las blockchains para
hacer que esta tecnología sea más adoptable. En la parte superior de la lista de estos problemas se encuentra la escalabilidad y luego la privacidad, las cuales son limitaciones significativas. La falta de escalabilidad es una preocupación general, donde las cadenas de bloques no cumplen con los niveles de rendimiento adecuados que esperan los usuarios cuando la cadena se utiliza en una gran escala. La privacidad también es de suma importancia, especialmente porque se prevé el uso de blockchains en industrias que exigen privacidad. Existen requisitos específicos en torno a la confidencialidad de las transacciones en las industrias financiera, jurídica y sanitaria, por ejemplo. Estos dos problemas están convirtiéndose en factores inhibidores hacia la aceptación más amplia de la tecnología blockchain. Se presentará una revisión de la investigación actualmente propuesta y en curso en estas dos áreas específicas a lo largo de este post. Además de la escalabilidad y la privacidad, otros desafíos que enfrenta blockchain incluyen la regulación, la integración, la interoperabilidad, la adaptabilidad y la seguridad en general. Aunque las blockchains en general poseen una seguridad bastante buena de serie; por ejemplo, Bitcoin ha resistido la prueba del tiempo y todavía es extremadamente seguro: todavía hay algunas advertencias que pueden permitir que la seguridad se vea comprometida. Además, existen algunas preocupaciones de seguridad razonables en otras cadenas de bloques como Ethereum con respecto a los contratos inteligentes, los ataques de denegación de servicio (DoS) y una gran superficie de ataque. Todo estos temas se analizarán en detalle en las siguientes secciones, que son las siguientes:
Escalabilidad
• Privacidad
• Seguridad
• Otros desafíos

Ahora, comenzaremos con la escalabilidad, uno de los mayores desafíos de blockchain.

Suscríbete o cómpralo para obtener acceso

Lee más contenido de este tipo suscribiéndote o compra el curso hoy mismo.

planos blockchain

Andrew ha propuesto otro enfoque para abordar las limitaciones en blockchains
Miller y col. y otros en su documento de posición On Scaling Decentralized Blockchains (disponible en
https://doi.org/10.1007/978-3-662-53357-4_8) En este documento, se muestra que una cadena de bloques puede
dividirse en varias capas abstractas llamadas planos. Cada avión es responsable de realizar
funciones específicas. Estos incluyen el plano de red, plano de consenso, plano de almacenamiento, plano de vista y
plano lateral. Esta abstracción permite abordar las limitaciones en cada plano individualmente y en un
de manera estructurada, que luego da como resultado una solución de escalabilidad general. Una breve descripción de cada
La capa se proporciona en las siguientes subsecciones con algunas referencias al sistema Bitcoin.

plano de red

Primero, discutiremos el plano de la red. El artículo sobre el escalado de cadenas de bloques descentralizadas mencionado
identifica previamente que, en Bitcoin, el plano de la red infrautiliza el ancho de banda de la red en
con respecto a la propagación de transacciones, que es una de sus funciones clave. Esta limitación transpira
debido a la forma en que el protocolo Bitcoin duplica efectivamente las transmisiones de transacciones. Primero, local
Se produce la validación de transacciones, donde el protocolo propaga todas las transacciones. Luego, después de la minería,
se produce la propagación en bloque, que contiene nuevamente transacciones previamente difundidas.

Cabe señalar que este problema fue abordado por BIP 152 (Compact Block
Relay:

https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

plano del consenso

La segunda capa se llama plano de consenso. Esta capa es responsable de la minería y
lograr el consenso. Los cuellos de botella en esta capa giran en torno a las limitaciones en la Prueba de trabajo
(PoW), mediante los cuales el aumento de la velocidad de consenso y el ancho de banda da como resultado un compromiso
la seguridad de la red debido a un aumento en el número de bifurcaciones.

plano de almacenamiento

El plano de almacenamiento es la tercera capa, que almacena el libro mayor. Los problemas de esta capa giran en torno a
la necesidad de que cada nodo guarde una copia de todo el libro mayor, lo que conduce a ciertas ineficiencias,
como un mayor ancho de banda y requisitos de almacenamiento. Bitcoin tiene un método disponible
llamado poda, que permite que un nodo funcione sin la necesidad de mantener la cadena de bloques completa
en su almacenamiento. Podar significa que cuando un nodo de Bitcoin ha descargado la cadena de bloques y
validado, borra los datos antiguos que ya ha validado. Esto ahorra espacio de almacenamiento. Esta
La funcionalidad ha dado lugar a importantes mejoras desde la perspectiva del almacenamiento.

plano de vistA

El siguiente en la lista es el plano de vista, que propone una optimización basada en la propuesta.
que los mineros de Bitcoin no necesitan la cadena de bloques completa para operar, y que una vista puede ser
construido a partir del libro mayor completo como una representación del estado completo del sistema,
que es suficiente para que funcionen los mineros. La implementación de vistas eliminará la necesidad de
nodos de minería para almacenar la cadena de bloques completa.

PLANO LATERAL

Finalmente, está el plano lateral, que representa la idea de transacciones fuera de la cadena. Esto es
el proceso mediante el cual se utiliza el concepto de canales de pago o transacción para descargar la
procesamiento de transacciones entre participantes. Sin embargo, todavía está respaldado por el principal Bitcoin.
blockchain.
Cabe señalar que este problema fue abordado por BIP 152 (Compact Block
Retransmisión, https://github.com/bitcoin/bips/blob/master/bip-0152.
mediawiki).
Escalabilidad y otros desafíos
[710]
Claramente, este modelo basado en aviones se puede utilizar para describir limitaciones y mejoras en
diseños actuales de blockchain de una manera estructurada y dirigida.
Además, hay varias otras estrategias generales que se han propuesto en los últimos años.
que puede abordar las limitaciones en los diseños actuales de blockchain, como Ethereum y Bitcoin.
Estos enfoques se caracterizarán y analizarán individualmente en la siguiente sección.

METODOS PARA MEJORAR LA ESCALABILIDAD

Dado que se trata de un área de investigación muy activa, a lo largo de los años muchas técnicas y propuestas han
se ha realizado para abordar el problema de escalabilidad de blockchain. En esta sección, presentaremos muchos de
estas técnicas.
Podemos dividir los enfoques para resolver problemas de escalabilidad en tres categorías principales según el
capa en la pila de blockchain en la que operan.
Describimos estas categorías aquí:
• Métodos de capa 0, o métodos de capa de red, donde los mecanismos para mejorar la escalabilidad
operan a nivel de red de la pila de arquitectura blockchain.
• Los métodos de capa 1 también se denominan métodos en cadena, donde el protocolo blockchain en sí es
mejorado para mejorar la escalabilidad. Esta capa representa la propia cadena de bloques.
• Métodos de capa 2, o métodos fuera de la cadena, donde los mecanismos que no son parte del
blockchain y existen fuera de la cadena de bloques principal se utilizan para mejorar la escalabilidad
de la cadena de bloques.
La escalabilidad tiene dos facetas. Uno es aumentar la velocidad de procesamiento de las transacciones y el otro
es el aumento en el número de nodos en la red. Ambos son deseables en muchas situaciones;
sin embargo, la velocidad de las transacciones es más buscada en las redes públicas.

Tenga en cuenta que el modelo descrito anteriormente, que analiza la cadena de bloques
apilar como una combinación de diferentes planos, es un concepto diferente al
modelo de capas mencionado en esta sección, que ve la pila de blockchain
ligeramente diferente. Sin embargo, existe cierta superposición, por ejemplo, cuando
decimos plano lateral, también nos referimos a la Capa 2. De manera similar, el plano de consenso puede
ser visto como un componente de Capa 1.

CAPA 0 – SOLUCION DE RED

Describiremos algunas de las soluciones de Capa 0, o capa de red, en las siguientes secciones.

KADKAST

Este es un nuevo protocolo que permite una propagación de bloques rápida, eficiente y segura para Bitcoin.
red blockchain.

Más información está disponible en el Paper: Rohrer, E. and Tschorsch,
F., 2019, October. Kadcast: A structured approach to broadcast in blockchain
networks. In Proceedings of the 1st ACM Conference on Advances in
Financial Technologies (pp. 199-213).
https://dl.acm.org/doi/pdf/10.1145/3318041.3355469

bloxroute

Otra solución de capa de red es bloXroute, que tiene como objetivo abordar los problemas de escalabilidad mediante
creando una red de distribución blockchain sin confianza.

Más información sobre bloXroute está disponible en https://bloxroute.com y en el siguiente documento técnico:

A continuación, pasemos a algunas soluciones centrales en cadena o soluciones de Capa 1.

capa 1 – soluciones onchain

En esta sección, describiremos las soluciones de Capa 1, o en cadena, que apuntan a la cadena de bloques central
elementos tales como bloques, transacciones y otras estructuras de datos en cadena para abordar la
problema de escalabilidad.

paralelizacion de transacciones

Por lo general, en los diseños de blockchain, las transacciones se ejecutan de forma secuencial. Por ejemplo, en
Ethereum, toda la ejecución de transacciones es secuencial, lo que permite que sea segura y consistente. Esta
También plantea la pregunta de que si, de alguna manera, las ejecuciones de transacciones se pueden realizar en paralelo, sin
comprometiendo la consistencia y seguridad de la cadena de bloques, resultaría en mucho mejor
actuación.
Ya se han hecho algunas sugerencias para Ethereum, por ejemplo:
• Fácil paralelización, que introduce un nuevo tipo de transacción: https://github.com/
ethereum / EIPs / issues / 648.
• Paralelización de transacciones en Ethereum, que propone un mecanismo para habilitar
ejecución de transacciones paralelas en Ethereum. El documento está disponible aquí: https: // arxiv.
org / pdf / 1901.09942.pdf.
Sin embargo, en el momento de escribir este artículo, ninguna de estas ideas está lista para la producción. Actualmente,
Hyperledger Sawtooth será la única cadena de bloques que admita transacciones paralelas y
listo para ser utilizado en producción. Discutimos Sawtooth en detalle en el Capítulo 17, Hyperledger.

incremento del tamaño de bloque

Esta es la propuesta más debatida para aumentar el rendimiento de blockchain (transacción
rendimiento de procesamiento). Actualmente, Bitcoin puede procesar solo entre tres y siete transacciones
por segundo, que es un factor inhibidor importante en la adaptación de la cadena de bloques de Bitcoin para el procesamiento
microtransacciones. El tamaño del bloque en Bitcoin está codificado en 1 MB, pero si el tamaño del bloque es
aumentado, puede contener más transacciones y puede resultar en un tiempo de confirmación más rápido. Existen
Varias propuestas de mejora de Bitcoin (BIP) realizadas a favor del aumento del tamaño del bloque. Estas
incluyen BIP 100, BIP 101, BIP 102, BIP 103 y BIP 109.
En Ethereum, el tamaño del bloque no está limitado por la codificación; en cambio, está controlado por un límite de gas.
En teoría, no hay límite en el tamaño de un bloque en Ethereum porque depende de la
cantidad de gas, que puede aumentar con el tiempo. Esto es posible porque a los mineros se les permite
aumente el límite de gas para los bloques posteriores si se alcanzó el límite en el bloque anterior.
Bitcoin Segregated Witness (SegWit) ha abordado este problema separando los datos de los testigos de
datos de transacciones, lo que resultó en más espacio para las transacciones. Otras propuestas para Bitcoin
incluyen Bitcoin Unlimited, Bitcoin XT y Bitcoin Cash. Puede consultar el Capítulo 6, Introducción
Bitcoin, para más detalles.

Una excelente reseña de referencias históricas y discusiones está disponible en: https://en.bitcoin.it/wiki/Block_size_limit_controversy.

Para obtener más información sobre las propuestas de Bitcoin, consulte lo siguiente
direcciones:

https://www.bitcoinunlimited.info

https://www.bitcoincash.org

reduccion del intervalo de bloque

Esta es otra propuesta sobre la reducción del tiempo entre cada generación de bloques. El tiempo
entre bloques se puede reducir para lograr una finalización más rápida de los bloques, pero puede resultar en
menos seguridad debido al mayor número de horquillas. Ethereum ha logrado un tiempo de bloqueo de
aproximadamente 14 segundos.
Esta es una mejora significativa de la cadena de bloques de Bitcoin, que tarda 10 minutos en
generar un nuevo bloque. En Ethereum, el problema de la gran cantidad de bloques huérfanos como resultado de
Los tiempos entre bloques se mitigan mediante el uso del subárbol observado más pesado codicioso (GHOST)
protocolo, por el cual los bloques huérfanos o obsoletos (también llamados tíos en la cadena Ethereum) son
también se incluye en la determinación de la cadena válida. Una vez que Ethereum pasa a Proof of Stake (PoS),
esto se volverá irrelevante ya que no se requerirá minería y la finalidad casi inmediata de
las transacciones se pueden lograr.

Tablas de búsqueda Bloom invertible

Este es otro enfoque que se ha propuesto para reducir la cantidad de datos necesarios para
ser transferido entre los nodos de Bitcoin. Las tablas de búsqueda de Bloom invertible (IBLT) fueron
propuesto originalmente por Gavin Andresen, y el atractivo clave de este enfoque es que
no resulta en un hard fork de Bitcoin si se implementa. La idea clave se basa en el hecho de que
no es necesario transferir todas las transacciones entre nodos; en cambio, solo aquellos que no son
ya disponibles en el grupo de transacciones del nodo de sincronización se transfieren. Esto permite más rápido
sincronización del grupo de transacciones entre nodos, aumentando así la escalabilidad general y
velocidad de la red Bitcoin.

sharding

La fragmentación no es una técnica nueva y se ha utilizado en bases de datos distribuidas para la escalabilidad, como
como MongoDB y MySQL. La idea clave detrás de la fragmentación es dividir las tareas en múltiples
fragmentos que luego son procesados por varios nodos. Esto da como resultado un rendimiento mejorado y
requisitos de almacenamiento reducidos. En blockchains, se emplea un esquema similar, por el cual el estado
de la red se divide en varios fragmentos. El estado generalmente incluye saldos, código,
nonce y almacenamiento. Los fragmentos son particiones débilmente acopladas de una cadena de bloques que se ejecutan en el mismo
red. Hay algunos desafíos relacionados con la comunicación entre fragmentos y el consenso sobre el
historia de cada fragmento. Esta es un área de investigación abierta y ha sido ampliamente estudiada en el
contexto de Ethereum 2.0.

blockchains privadas

La mayoría de las cadenas de bloques privadas son intrínsecamente más rápidas porque no se requiere una descentralización real
y los participantes en la red no necesitan minar usando PoW; en cambio, solo pueden
validar transacciones. Esto se puede considerar como una solución al problema de escalabilidad en público
cadenas de bloques; sin embargo, esta no es la solución al problema de escalabilidad. Además, debería ser
señaló que las cadenas de bloques privadas solo son adecuadas en áreas específicas y configuraciones como empresas
entornos, donde todos los participantes son conocidos

proof of stake

Las cadenas de bloques basadas en algoritmos de PoS son fundamentalmente más rápidas porque los algoritmos de PoS no
requieren la realización de PoW que consumen tiempo y energía. PoS se explicó en detalle en
Capítulo 5, Algoritmos de consenso.

propagacion de bloque

Además de la propuesta anterior, también se ha sugerido la canalización de la propagación de bloques,
que se basa en la idea de anticipar la disponibilidad de un bloque. En este esquema, el
la disponibilidad de un bloque ya se anuncia sin esperar la disponibilidad real del bloque, por lo que
reduciendo el tiempo de ida y vuelta entre nodos. Finalmente, el problema de las largas distancias entre
el originador de transacciones y los nodos también contribuyen a la desaceleración de la propagación de bloques. Eso
se ha demostrado en la investigación realizada por Christian Decker et al. que la conectividad aumente
puede reducir el retardo de propagación de bloques y transacciones. Esto es posible porque, si en alguna
una vez que el nodo de Bitcoin está conectado a muchos otros nodos, puede acelerar la información
propagación en la red.
Escalabilidad y otros desafíos
[714]
Una solución elegante para los problemas de escalabilidad probablemente será una combinación de algunos o todos
los enfoques generales antes mencionados. Varias iniciativas tomadas para abordar
Los problemas de escalabilidad y seguridad en blockchains están ahora casi listos para su implementación o
ya implementado. Por ejemplo, Bitcoin SegWit es una propuesta que puede ayudar enormemente con
escalabilidad y solo necesita una bifurcación suave para su implementación. La idea clave detrás de
llamado SegWit es para separar los datos de la firma de las transacciones, lo que resuelve la transacción
problema de maleabilidad y permite aumentar el tamaño del bloque, lo que resulta en un mayor rendimiento.

bitcoin-ng

Otra propuesta, Bitcoin-NG, que se basa en la idea de microbloques y elección de líder,
ha ganado algo de atención recientemente. La idea central es dividir bloques en dos tipos, a saber, líder
bloques (también llamados bloques clave) y microbloques:
• Bloques de líderes: estos son responsables de PoW, mientras que los microbloques contienen
actas.
• Microbloques: estos no requieren ningún PoW y son generados por el líder electo
cada ciclo de generación de bloques. Este ciclo de generación de bloques es iniciado por un bloque líder.
El único requisito es firmar los microbloques con la clave privada del líder electo.
Los microbloques pueden ser generados a muy alta velocidad por el líder electo (minero),
lo que resulta en un mayor rendimiento y velocidad de transacción.
Por otro lado, el Ethereum 2.0 Mauve Paper, escrito por Vitalik Buterin y presentado en
Ethereum Devcon2 en Shanghai, describe una visión diferente de una cadena de bloques escalable.
Esta propuesta se basa en una combinación de fragmentación y una implementación del PoS
algoritmo de consenso. El documento definió ciertos objetivos, como ganar eficiencia a través de PoS,
minimizando el tiempo de bloqueo y asegurando la finalidad económica, la escalabilidad, la comunicación entre fragmentos,
y resistencia a la censura.

El papel malva está disponible en:

https://docs.google.com/document/d/1maFT3cpHvwn29gLvtY4WcQiI6kRbN_nbCf3JlgR3m_8/edit#

El papel malva es la visión de Ethereum 2.0, que ahora se está convirtiendo en
una realidad. Hablamos de Ethereum 2.0, que se presentará con el
Actualización de Serenity, en el Capítulo 16, Serenity.

dags

DAG significa gráfico acíclico dirigido. Se ve como una alternativa a la tecnología blockchain.
Blockchain es fundamentalmente una lista enlazada, mientras que DAG es un gráfico acíclico donde los enlaces entre
los nodos tienen una sola dirección. La estructura DAG elimina la necesidad de minería y bloques,
que permite la creación y confirmación de transacciones en paralelo, logrando así una alta transacción
rendimiento. Un ejemplo de DAG es la criptomoneda IOTA. Más información sobre esto puede ser
que se encuentra en https://www.iota.org

mecanismos de consenso

Tradicionalmente, las cadenas de bloques se basan en algoritmos PoW o PoS, que son inherentemente lentos en
términos de desempeño. Especialmente PoW puede procesar solo unas pocas transacciones por segundo. Si
se utiliza un mecanismo de consenso diferente como Raft o PBFT, entonces la velocidad profesada puede
aumentar significativamente. Examinamos estos conceptos en el Capítulo 5, Algoritmos de consenso en mayor
detalle.
Hasta ahora, hemos analizado la Capa 0 (soluciones basadas en red) y la Capa 1 (soluciones en cadena) para
el problema de la escalabilidad. En la siguiente sección, presentaremos otro enfoque que tiene como objetivo resolver el
problema de escalabilidad mediante el uso de componentes fuera de la cadena o de Capa 2.

capa 2 – soluciones multichain y off-chain

Las soluciones de Capa 2 se basan en la idea de que en lugar de modificar la cadena principal para lograr
escalabilidad, el objetivo debería ser descargar parte del procesamiento a mecanismos más rápidos
fuera de la cadena subyacente principal, procese allí y luego escriba el resultado en el
cadena principal como garantía de integridad. Aquí se describen varias de estas técnicas.

canales de estado

Este es otro enfoque propuesto para acelerar la transacción en una red blockchain.
La idea básica es utilizar canales secundarios para actualizar el estado y procesar transacciones fuera de la red principal.
cadena; Una vez finalizado el estado, se vuelve a escribir en la cadena principal, descargando así el tiempo
consumiendo operaciones de la cadena de bloques principal.
Los canales estatales funcionan realizando los siguientes tres pasos:

  1. Primero, una parte del estado de la cadena de bloques está bloqueada bajo un contrato inteligente, lo que garantiza la
    acuerdo y lógica empresarial entre los participantes.
  2. Ahora, se inicia la interacción y el procesamiento de transacciones fuera de la cadena entre los participantes.
    que actualizan el estado (solo entre ellos por ahora). En este paso, casi cualquier
    Se puede realizar una cantidad de transacciones sin requerir la cadena de bloques. Esto es
    lo que hace que el proceso sea tan rápido y posiblemente el mejor candidato para resolver blockchain
    problemas de escalabilidad. Se podría argumentar que esta no es una solución real en blockchain como
    como, por ejemplo, fragmentación, pero el resultado final es una red más rápida, más ligera y más robusta
    que puede resultar muy útil en redes de micropagos, redes de IoT y muchas otras
    aplicaciones.
  3. Una vez que se alcanza el estado final, el canal de estado se cierra y se escribe el estado final
    de vuelta a la cadena de bloques principal. En esta etapa, la parte bloqueada de la cadena de bloques también es
    desbloqueado.
    Escalabilidad y otros desafíos
    [716]
    Este proceso se muestra en el siguiente diagrama:
Canales de estado

Esta técnica se ha utilizado en la red Bitcoin Lightning y en Raiden de Ethereum.
La diferencia clave entre Lightning y Raiden es que Lightning solo funciona para Bitcoin
transacciones, mientras que Raiden admite todos los tokens compatibles con ERC20, lo que hace que la red Raiden
una opción más flexible.

cadenas laterales

Las cadenas laterales pueden mejorar la escalabilidad indirectamente al permitir que muchas cadenas laterales se ejecuten junto con
la cadena de bloques principal, mientras que permite el uso de quizás comparativamente menos seguro y más rápido
cadenas laterales para realizar transacciones, pero que aún están vinculadas con la cadena de bloques principal. El núcleo
La idea de las cadenas laterales se denomina clavija bidireccional, que permite la transferencia de monedas de un padre.
cadena a una cadena lateral y viceversa.

sub-chains

Esta es una técnica relativamente nueva propuesta recientemente por Peter R. Rizun y se basa en la idea
de bloques débiles, que se crean en capas hasta que se encuentra un bloque fuerte.
El artículo de investigación de las subcadenas de Rizun está disponible en:

https://doi.org/10.5195/ledger.2016.40. Rizun, P. R. (2016). Subchains: A
Technique to Scale Bitcoin and Improve the User Experience. Ledger, 1, 38-52.
Los bloques débiles se pueden definir como aquellos bloques que no se han podido extraer al reunir
los criterios de dificultad de red estándar, pero han trabajado lo suficiente para cumplir con otro más débil
objetivo de dificultad. Los mineros pueden construir subcadenas colocando bloques débiles uno encima del otro,
a menos que se encuentre un bloque que cumpla con el objetivo de dificultad estándar.
En este punto, la subcadena se cierra y se convierte en el bloque fuerte. Ventajas de este enfoque
incluir tiempo de espera reducido para la primera verificación de una transacción. Esta técnica también resulta
en una posibilidad reducida de bloqueos huérfanos y una aceleración del procesamiento de transacciones. Esto es
también una forma indirecta de abordar el problema de la escalabilidad. Las subcadenas no requieren horquilla blanda
o bifurcación difícil de implementar, pero necesita la aceptación de la comunidad.

cadenas de arboles

También hay otras propuestas para aumentar la escalabilidad de Bitcoin, como las cadenas de árboles, que
cambie el diseño de la cadena de bloques de un modelo linealmente secuencial a un árbol. Este árbol es básicamente
un árbol binario que desciende de la cadena principal de Bitcoin. Este enfoque es similar a la cadena lateral
implementación, eliminando la necesidad de cambios importantes en el protocolo o aumento del tamaño del bloque. Permite
rendimiento de transacciones mejorado. En este esquema, las propias blockchains están fragmentadas
y distribuido por la red para lograr escalabilidad.
Además, la minería no es necesaria para validar los bloques en las cadenas de árboles; en cambio, los usuarios pueden
verificar de forma independiente el encabezado del bloque. Sin embargo, esta idea aún no está lista para la producción y
se requiere más investigación para que sea práctico.
Además de las técnicas generales mencionadas anteriormente, algunas mejoras específicas de Bitcoin han
También ha sido propuesto por Christian Decker (gran parte del trabajo de Decker se puede encontrar aquí: https: //
scholar.google.ch/citations?user=ZaeGlZIAAAAJ&hl=en) en su libro Sobre la escalabilidad y
seguridad de Bitcoin. Esta propuesta se basa en la idea de acelerar el tiempo de propagación a medida que
El mecanismo de propagación de información actual da como resultado bifurcaciones de blockchain. Estas tecnicas
incluyen la minimización de la verificación, la canalización de la propagación de bloques y el aumento de la conectividad.
Estos cambios no requieren cambios fundamentales a nivel de protocolo; en cambio, estos cambios pueden ser
implementado de forma independiente en el software del nodo Bitcoin.
Con respecto a la minimización de la verificación, se ha observado que el proceso de verificación de bloques es
contribuyendo al retraso de la propagación. La razón detrás de esto es que un nodo lleva mucho tiempo
para verificar la unicidad del bloque y las transacciones dentro del bloque. Se ha sugerido
que un nodo puede enviar el mensaje de inventario tan pronto como el PoW inicial y la validación del bloque
se completan los controles. De esta manera, la propagación se puede mejorar simplemente realizando el primer
Verificación de dificultad y no esperar a que finalice la validación de la transacción.

La idea original fue propuesta en el siguiente trabajo de investigación: https: //
eprint.iacr.org/2016/545.pdf.

plasma

Otra propuesta de escalabilidad reciente es Plasma, que ha sido propuesta por Joseph Poon
y Vitalik Buterin. Esta propuesta describe la idea de ejecutar contratos inteligentes en la raíz
blockchain (Ethereum mainnet), y tener blockchains secundarios que realizan un alto número de
transacciones, para retroalimentar pequeñas cantidades de compromisos con la cadena matriz. En este esquema,
las cadenas de bloques se organizan en una jerarquía de árbol con la minería realizada solo en la raíz (principal)
blockchain, que alimenta las pruebas de seguridad hasta las child chains. Esta es también una capa 2
sistema ya que, al igual que los canales estatales, Plasma también opera fuera de la cadena.

El artículo de investigación sobre contratos de plasma está disponible en http://plasma.io.

cadenas de confirmacion

Las cadenas de compromiso son un término más genérico para la propuesta de Plasma de Vitalik Buterin. Ellos son también
denominadas cadenas laterales sin custodia pero sin un nuevo mecanismo de consenso, como es el caso
con cadenas laterales. Se basan en el mecanismo de consenso de la cadena principal, por lo que pueden considerarse
tan seguro como la cadena principal. El operador de la cadena de compromiso es responsable de facilitar
comunicación entre los participantes en la transacción y envío de actualizaciones periódicas a los principales
cadena.

Más información sobre cadenas de compromiso está disponible aquí:

Khalil, R., Zamyatin,
A., Felley, G., Moreno-Sanchez, P. and Gervais, A., 2018. Commit-Chains:
Secure, Scalable Off-Chain Payments. Cryptology ePrint Archive, Report
2018/642, 2018. https://eprint.iacr.org/2018/642.pdf.

zk-rollups

Zk-Rollups es una solución de Capa 2 que permite agrupar múltiples transacciones en una sola
transacción. Este enfoque permite el procesamiento de transferencias masivas utilizando una sola transacción, que
mejora la escalabilidad.

En este documento se describe una solución de verificación escalable para blockchains:

https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf.

Más información sobre una solución de escalabilidad basada en confianza
El hardware se puede encontrar aquí: https://truebit.io/.

Otras técnicas de escalabilidad incluyen enfoques de cadenas múltiples. Uno de los principales ejemplos de tales
técnicas es Polkadot, que describiremos brevemente más adelante en este capítulo en el contexto de
interoperabilidad. Sin embargo, este mecanismo también proporciona escalabilidad.
Con esto, hemos completado nuestra discusión sobre algunas de las muchas posibilidades de escalabilidad
mejoras de blockchain. En la siguiente sección, analizaremos la privacidad y algunas
técnicas para lograr privacidad en blockchain.

privacidad

La privacidad en blockchain se puede dividir en dos categorías principales según el tipo de servicio
necesario. Estas categorías son el anonimato de los usuarios y la confidencialidad de los
actas. El anonimato se refiere a ocultar la identidad del remitente o del destinatario,
mientras que la confidencialidad aborda los requisitos de ocultar los valores de las transacciones.

anonimato

El anonimato es deseable en situaciones en las que se requiere ocultar la identidad de los usuarios.
otros participantes de la red. Esto puede deberse a requisitos reglamentarios, empresas
requisitos, o simplemente debido a la naturaleza sensible de las transacciones. Por ejemplo, en una empresa
red, puede ser conveniente ocultar los tratos entre los diferentes participantes en el
red de otros competidores para evitar fricciones o ventajas competitivas comerciales injustificadas.
Las propiedades de desvinculación e imposibilidad de rastrear se utilizan para lograr el anonimato.
La propiedad de la imposibilidad de rastrear permite ocultar el rastro de una transacción de una parte
a otro. Por otro lado, la desvinculación significa que un observador no puede deducir el vínculo
entre las transacciones y sus participantes, o las relaciones entre los participantes de la transacción
(remitentes y receptores). También discutimos el anonimato en el Capítulo 9, Monedas alternativas, en mayor
detalle.

confidencialidad

La confidencialidad es un requisito absoluto en muchas industrias como las finanzas, el derecho y la salud.
Del mismo modo, la privacidad de las transacciones es una propiedad muy deseada de las cadenas de bloques. Sin embargo, debido a su
muy natural, especialmente en blockchains públicas, todo es transparente, inhibiendo así su uso
en diversas industrias donde la privacidad es de suma importancia, como finanzas, salud y
muchos otros.
Hay diferentes propuestas que se han hecho para abordar el tema de la privacidad y algunas
ya se ha avanzado. Varias técnicas, como la ofuscación de indistinguibilidad,
cifrado homomórfico, pruebas de conocimiento cero (ZKP) y firmas de anillo, todas han sido
investigado e implementado. Todas estas técnicas tienen sus méritos y deméritos y serán
discutido en las siguientes secciones.

tecnicas pata lograr privacidad

En esta sección, describiremos diferentes técnicas para lograr la privacidad, incluido el anonimato y
confidencialidad.
Escalabilidad y otros desafíos
[720]
Similar a las soluciones de escalabilidad, también podemos dividir las soluciones de privacidad en tres categorías, basadas
en la capa dentro de la pila de arquitectura blockchain que operan:
• Métodos de capa 0, o métodos de capa de red, donde el mecanismo para lograr la privacidad
opera a nivel de red.
• Métodos de capa 1, también llamados métodos en cadena, donde el protocolo blockchain en sí es
mejorado para lograr privacidad.
• Métodos de capa 2, o métodos fuera de la cadena, donde los mecanismos que existen fuera de la
blockchain se utilizan para lograr privacidad en blockchain.
Como muchas de las técnicas descritas en las siguientes secciones se pueden utilizar en las Capas 1 y 2:
por ejemplo, pruebas de conocimiento cero: no estamos distinguiendo entre estas capas. En lugar,
Solo enumeraremos estas soluciones y discutiremos para qué se pueden usar. Además, las soluciones
para el anonimato y la confidencialidad también se superponen y las técnicas utilizadas para lograr la confidencialidad
también son más o menos aplicables para lograr el anonimato. Sin embargo, segregamos la Capa 0,
la capa de red, y describa algunos de los enfoques de red para lograr el anonimato, antes
pasando a introducir una gama de mecanismos de privacidad que son aplicables en las Capas 1 y 2.

capa 0

Estas soluciones son métodos de nivel de capa de red que proporcionan anonimato mediante el uso de TOR e I2P.
Estos métodos permiten ocultar las identidades de las partes involucradas.

tor

Tor, el Onion Router, es un software que permite comunicaciones anónimas. Más
La información sobre Tor está disponible aquí: https://www.torproject.org. Podemos usar Tor para habilitar
comunicación anónima en redes blockchain de criptomonedas. Tor es una opción común
para permitir la comunicación anónima y se ha utilizado en Monero, Verge y en Bitcoin para
proporcionar anonimato.
Para Bitcoin, consulte https://en.bitcoin.it/wiki/Tor. Monero también se puede ejecutar con Tor (https: //
web.getmonero.org/). Verge es otro ejemplo de criptomoneda que utiliza Tor para IP
ofuscación.

i2p

I2P, Invisible Internet Project, es una red anónima construida en Internet. Permite
comunicación entre pares resistente a la censura. Se usa en Monero para brindar anonimato
servicios. Más información sobre I2P está disponible aquí: https://geti2p.net/en/

Monero y Zcash, que pueden considerarse una horquilla ligera de Monero,
son ejemplos de cadenas de bloques de criptomonedas que admiten anónimos
actas. Monero hace uso de firmas de anillo, direcciones ocultas y
transacciones confidenciales, mientras que Zcash usa zk-SNARKs.

capas 1 y 2

Otras capas incluyen las soluciones Layer 1 y Layer 2, que presentaremos a continuación.

Ofuscación de indistinguibilidad

Esta técnica criptográfica puede servir como una solución milagrosa para toda privacidad y confidencialidad.
problemas en blockchains, pero la tecnología aún no está lista para implementaciones de producción.
La ofuscación indistinguible (IO) permite la ofuscación del código, que es una investigación muy madura
tema en criptografía. Si se aplica a blockchains, IO puede servir como una ofuscación irrompible
mecanismo que convertirá los contratos inteligentes en una caja negra donde el comportamiento de los ofuscados
el código es indistinguible. En palabras más simples, la funcionalidad interna del contrato inteligente es
totalmente escondido.
La idea clave detrás de IO es lo que los investigadores llaman un rompecabezas multilineal, que básicamente
ofusca el código del programa mezclándolo con elementos aleatorios, y si el programa se ejecuta como
previsto, producirá el resultado esperado. Sin embargo, cualquier otra forma de ejecutarlo
hacer que el programa parezca datos basura aleatorios. Esta idea fue propuesta por primera vez por Sanjam Garg
et al. en su artículo de investigación Candidate Indistinguishability Ofuscation and Functional Encryption
para todos los circuitos.

Este artículo de investigación está disponible en https: //eprint.iacr.
org / 2013 / 451.pdf.

encriptaCION HOMOMORFICA

Este tipo de cifrado permite realizar operaciones sobre datos cifrados. Imagina un
escenario donde los datos se envían a un servidor en la nube para su procesamiento. El servidor lo procesa y
devuelve la salida sin saber nada sobre los datos que ha procesado. Esto también es
un área propicia para la investigación y el cifrado totalmente homomórfico, que permite todas las operaciones en
datos cifrados, todavía no se pueden implementar completamente en producción; Sin embargo, un gran avance en este
El campo ya se ha realizado. Una vez implementado en blockchains, puede permitir el procesamiento en
texto cifrado, que permitirá la privacidad y confidencialidad de las transacciones de forma inherente.
Por ejemplo, los datos almacenados en la cadena de bloques se pueden cifrar utilizando homomorphic
cifrado, y los cálculos se pueden realizar en esos datos sin la necesidad de descifrar,
proporcionando así un servicio de privacidad en blockchains. Este concepto también se ha implementado en un
proyecto llamado Enigma, que está disponible en línea en https://www.media.mit.edu/projects/
enigma / overview /, del Media Lab del MIT. Enigma es una red peer-to-peer que permite múltiples
partes para realizar cálculos sobre datos cifrados sin revelar nada sobre los datos.

La investigación original está disponible en https://crypto.stanford.edu/
craig /.

PRUEBAS DE CONOCIMIENTO CERO

Los ZKP se han implementado recientemente en Zcash con éxito, como se ve en el Capítulo 9,
Monedas alternativas. Más específicamente, el argumento sucinto no interactivo del conocimiento
(SNARK) se han implementado para garantizar la privacidad en la cadena de bloques.
La misma idea se puede implementar en Ethereum y otras cadenas de bloques también. Integrando Zcash
en Ethereum ya es un proyecto de investigación muy activo dirigido por Ethereum Research &
Equipo de desarrollo y empresa Zcash.
Hay una adición reciente a la familia de ZKP llamada Succinct Transparente de conocimiento cero
Argument of Knowledge (zk-STARK), que es una mejora en zk-SNARKs en el sentido
que los zk-STARK consumen mucho menos ancho de banda y almacenamiento. Además, no requieren la inicial,
configuración algo controvertida y confiable que se requiere para zk-SNARKs. Además, zk-STARKs
son mucho más rápidos ya que no hacen uso de curvas elípticas ni dependen de hashes.
Bulletproofs son pruebas cortas no interactivas de conocimiento cero. No requieren una configuración confiable.
Este esquema permite que un probador demuestre que un número cifrado está dentro de un rango de números
sin revelar ninguna otra información sobre el número.

El artículo de investigación original está disponible en https: //eprint.iacr.
org / 2013 / 879.pdf. Otro excelente documento está disponible aquí:

http://chriseth.github.io/notes/articles/zksnarks/zksnarks.pdf.

El artículo de investigación original para zk-STARKs está disponible aquí: https: //
eprint.iacr.org/2018/046.pdf.
Un mecanismo de preservación de la privacidad basado en zk-SNARKs se llama Nightfall.
Más información sobre Nightfall está disponible en:

https://github.com/EYBlockchain/nightfall.

Más información sobre Bulletproofs está disponible aquí:

Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P. and Maxwell, G.,
2018, May. Bulletproofs: Short proofs for confidential transactions and more. In
2018 IEEE Symposium on Security and Privacy (SP) (pp. 315-334). IEEE.
https://electroneropulse.org/public/doc/Bulletproof%20
RingCT.pdf.

CANALES DE ESTADO

La privacidad utilizando canales estatales también es posible, simplemente debido al hecho de que todas las transacciones se ejecutan
fuera de la cadena, y la cadena de bloques principal no ve la transacción en absoluto, excepto por el estado final
salida, que garantiza la privacidad y confidencialidad.

COMPUTACION SEGURA MULTIPARTE

El concepto de cómputo multiparte seguro no es nuevo y se basa en la noción de que los datos son
dividido en múltiples particiones entre las partes participantes, bajo un mecanismo de intercambio secreto,
que luego realiza el procesamiento real de los datos sin la necesidad de reconstruir los datos en un
sola máquina.
La salida producida después del procesamiento también se comparte entre las partes. Varias partes
realizar el cálculo mutuamente sin revelar sus entradas. Solo la salida del
se revela el cálculo.

Se propuso una plataforma de cálculo segura multiparte llamada Enigma
en 2015. El documento está disponible aquí:

https://web.media.mit.edu/~guyzys/data/enigma_full.pdf.

CONFIDENCIALIDAD ASISTIDA POR HARDWARE CONFIABLE

Se pueden utilizar plataformas informáticas confiables para proporcionar un mecanismo mediante el cual la confidencialidad
de una transacción se puede lograr en una cadena de bloques, por ejemplo, utilizando Intel Software Guard
Extension (SGX), que permite que el código se ejecute en un entorno protegido por hardware denominado
enclave. Una vez que el código se ejecuta con éxito en el enclave aislado, puede producir una prueba, llamada
cita, que es certificada por los servidores en la nube de Intel.
Es una preocupación que confiar en Intel resultará en algún nivel de centralización y no está en línea con
el verdadero espíritu de la tecnología blockchain. Sin embargo, esta solución tiene sus méritos y, en realidad,
muchas plataformas ya usan chips Intel de todos modos, por lo que confiar en Intel puede ser aceptable para algunos
algunos casos.
Si esta tecnología se aplica a contratos inteligentes, una vez que un nodo ha ejecutado el
contrato, puede producir una prueba de corrección, demostrando así una ejecución exitosa, y otros
Los nodos solo tendrán que verificarlo. Esta idea se puede ampliar aún más utilizando cualquier Trusted
Entorno de ejecución (TEE), que puede proporcionar la misma funcionalidad que un enclave y es
disponible incluso en dispositivos móviles con Near Field Communication (NFC) y un elemento seguro.
Por ejemplo, Ekiden es una plataforma que utiliza el TEE de Intel SGX para ejecutar contratos inteligentes.
preservando la confidencialidad.

Más información sobre Ekiden está disponible aquí:

Cheng, R., Zhang, F., Kos, J., He, W., Hynes, N., Johnson, N., Juels, A.,
Miller, A. and Song, D., 2019, June. Ekiden: A platform for confidentiality-
preserving, trustworthy, and performant smart contracts. In 2019 IEEE
European Symposium on Security and Privacy (EuroS&P) (pp. 185-200).
IEEE.
https://arxiv.org/pdf/1804.05141.

COINJOIN

CoinJoin es una técnica que se utiliza para anonimizar las transacciones de Bitcoin mezclándolas
interactivamente. La idea se basa en formar una sola transacción de múltiples entidades
sin provocar ningún cambio en las entradas y salidas. Elimina el vínculo directo entre remitentes
y receptores, lo que significa que una sola dirección ya no se puede asociar con transacciones,
lo que podría conducir a la identificación de los usuarios.
CoinJoin necesita cooperar entre múltiples partes que estén dispuestas a crear una
transacción mediante la mezcla de pagos. Por lo tanto, debe tenerse en cuenta que, si algún participante en
El esquema CoinJoin no se mantiene al día con el compromiso asumido de cooperar para crear un
transacción única, al no firmar las transacciones como se requiere, puede resultar en un ataque DoS.
En este protocolo, no es necesario un solo tercero de confianza. Este concepto es diferente de
mezclar un servicio, que actúa como un tercero o intermediario de confianza entre los usuarios de Bitcoin
y permite barajar transacciones. Esta mezcla de transacciones da como resultado la prevención de
rastrear y vincular pagos a un usuario en particular

TRANSACCIONES CONFIDENCIALES

Las transacciones confidenciales hacen uso de los compromisos de Pedersen para proporcionar
confidencialidad. Los esquemas de compromiso permiten al usuario comprometerse con algún valor mientras lo mantiene
secreto con la capacidad de revelarlo más tarde. Los esquemas de compromiso se pueden construir simplemente
mediante el uso de funciones hash criptográficas. Dos propiedades que deben satisfacerse para
diseñar un esquema de compromiso son vinculantes y encubridores.
La vinculación se asegura de que el confirmador no pueda cambiar el valor elegido una vez confirmado,
mientras que la propiedad oculta asegura que cualquier adversario no pueda encontrar el valor original para
que el autor se comprometió.
Un compromiso de Pedersen es un tipo de ocultación de información, compromiso computacionalmente vinculante
esquema, bajo un supuesto de logaritmo discreto. Los compromisos de Pedersen permiten
operaciones y preservar la propiedad conmutativa sobre los compromisos, que los hacen
particularmente útil para brindar confidencialidad en las transacciones de Bitcoin. En otras palabras, ellos
admitir el cifrado homomórfico parcial de valores, lo que significa que el uso de esquemas de compromiso
permite ocultar los valores de pago en una transacción de Bitcoin.

Este concepto ya está implementado en el Proyecto Elements:

https://elementsproject.org/features/confidential-transactions.

MINBLEWINBLE

El esquema MimbleWimble se propuso de forma algo misteriosa en el canal IRC de Bitcoin
y desde entonces ha ganado mucha popularidad. MimbleWimble amplía la idea de confidencialidad
transacciones y CoinJoin, que permiten la agregación de transacciones sin requerir ningún
interactividad. Sin embargo, no admite el uso del lenguaje de secuencias de comandos de Bitcoin, junto con
varias otras características del protocolo estándar de Bitcoin. Esto lo hace incompatible con el
protocolo Bitcoin existente. Por lo tanto, se puede implementar como una cadena lateral de Bitcoin o en
propia como una criptomoneda alternativa.
Este esquema puede abordar problemas de privacidad y escalabilidad a la vez. Los bloques creados usando
la técnica MimbleWimble no contiene transacciones como en las cadenas de bloques tradicionales de Bitcoin;
en cambio, estos bloques se componen de tres listas: una lista de entrada, una lista de salida y algo
llamados excesos, que son listas de firmas y diferencias entre salidas e insumos.
La lista de entrada básicamente hace referencia a las salidas antiguas, y la lista de salida contiene información confidencial.
salidas de transacciones.
Los bloques creados usando el esquema MimbleWimble son verificables por nodos usando firmas,
entradas y salidas para garantizar la legitimidad del bloque. A diferencia de Bitcoin, MimbleWimble
Las salidas de transacciones solo contienen claves públicas, y la diferencia entre las salidas antiguas y nuevas es
firmado por todos los participantes involucrados en las transacciones.

PROTOCOLOS DE MEZCLADO

Un protocolo de mezcla, o mezclador, es un servicio que permite a los usuarios preservar su privacidad mezclando
sus monedas con otros usuarios. Hablamos de los mezcladores en detalle en el Capítulo 9, Monedas alternativas.

ENCRIPTACION BASADA EN ATRIBUTOS

El cifrado basado en atributos (ABE) es un tipo de criptografía de clave pública que proporciona
confidencialidad y control de acceso simultáneamente. La idea clave detrás de este esquema es que
la clave privada de un usuario y su texto cifrado dependen de los atributos del usuario, como
su ubicación, zona horaria o su función en la organización. Esto significa que el descifrado es solo
posible cuando no solo está disponible la clave privada, sino también los atributos coincidentes.

FIRMAS ANONIMAS

Las firmas anónimas son tipos de firmas digitales en las que las firmas no revelan la
identidad del firmante. Hay principalmente dos esquemas disponibles para firmas anónimas:
firmas de grupo y firmas de anillo.
Las firmas de grupo permiten que un conjunto de firmantes forme un grupo administrado por un administrador de grupo. Cada
El administrador del grupo emite una clave de firma de grupo al miembro del grupo. Este grupo
La clave de firma permite que cada miembro del grupo firme mensajes de forma anónima en nombre de
el grupo. El administrador del grupo puede determinar quién es el firmante del mensaje, mientras que
las entidades externas no pueden. Si bien las firmas de grupo pueden funcionar bien, una de las limitaciones de este
El esquema es que el administrador del grupo puede identificar a los usuarios. Este problema se solucionó con
firmas de anillo.
Escalabilidad y otros desafíos
[726]
Las firmas de anillo permiten que un conjunto de firmantes forme un grupo (un anillo) de miembros. Cada miembro en
este grupo puede firmar mensajes en nombre del anillo. A diferencia de las firmas de grupo, no hay
administrador de grupo en firmas de anillo, para que nadie pueda identificar a los firmantes.
Si bien todas estas técnicas son útiles y proporcionan muchas propiedades deseables de anonimato,
También existe el problema de utilizar esta tecnología de forma maliciosa. Imagínese si se usa mal el anonimato
por delincuentes involucrados en lavado de dinero o venta de drogas ilegales mediante el uso anónimo
criptomoneda. Sería casi imposible rastrear las actividades ilegales hasta el originador si
se logra el anonimato absoluto. Imagine un mercado de Silk Road (https://en.wikipedia.org/
wiki / Silk_Road_ (marketplace)) que utiliza criptomonedas anónimas. Cómo es posible
rastreado y detenido?

GESTORES DE PRIVACIDAD

Los administradores de privacidad proporcionan un mecanismo que brinda confidencialidad a las transacciones. Estos son
componentes fuera de la cadena que sustituyen la carga útil de la transacción con un índice hash, de tal manera
que solo aquellos participantes que son parte de la transacción pueden encontrar el correspondiente
carga útil cifrada representada por el índice hash. Otras partes que no están al tanto de la
transacción simplemente ignorará el hash. Este concepto se discutió en el Capítulo 20, Empresa
Blockchains.
Podemos visualizar muchas de las técnicas de privacidad de blockchain discutidas hasta ahora en este capítulo.
usando la siguiente tabla:

Taxonomia de alto nivel de las tecnicas de privacidad Blockchain

Aparte de la escalabilidad y la privacidad, hay varios otros aspectos generales de seguridad que deben
ser direccionado en blockchain. A continuación, describiremos estos temas generales de seguridad.

seguridad

Las cadenas de bloques son generalmente seguras y utilizan criptografía asimétrica y simétrica, como
requerido en toda la red blockchain, para garantizar que la capa central de la cadena de bloques sea
seguro. Sin embargo, todavía hay algunas advertencias que pueden resultar en comprometer la seguridad del
blockchain.
Hay algunos ejemplos de maleabilidad de transacciones, ataques de eclipse y la posibilidad de
doble gasto en Bitcoin que, en ciertos escenarios, han demostrado funcionar por varios
investigadores. La maleabilidad de la transacción abre la posibilidad de un doble retiro o depósito
al permitir que un pirata informático cambie la identificación única de una transacción antes de que la red Bitcoin pueda confirmar
esto, resultando en un escenario en el que parecería que las transacciones no ocurrieron. BIP 62 es uno de
las propuestas, junto con SegWit, que ha sugerido soluciones para resolver este problema. Debería ser
señaló que esto es un problema solo en el caso de transacciones no confirmadas; es decir, escenarios donde
Los procesos operativos se basan en transacciones no confirmadas. En el caso de aplicaciones normales que
solo confíe en transacciones confirmadas, esto no es un problema.
Los ataques de eclipse de información en Bitcoin pueden resultar en un doble gasto. La idea detrás del eclipse
ataques es que el nodo Bitcoin es engañado para que se conecte solo con las direcciones IP del nodo atacante. Esta
abre la posibilidad de un ataque del 51% por parte del atacante. Esto se ha abordado hasta cierto punto
en el cliente Bitcoin v0.10.1: hay más información disponible sobre el ataque y cómo se ha solucionado
aquí: http://cs-people.bu.edu/heilman/eclipse/.
Ahora, antes de seguir discutiendo la seguridad en blockchains, echemos un vistazo a lo interesante
tema de verificación formal. Este se está convirtiendo en un tema candente en el espacio blockchain, debido a su fuerte
méritos técnicos como técnica para abordar problemas de seguridad. Tenga en cuenta que esta no es una técnica nueva,
pero ha encontrado aplicaciones muy interesantes en la tecnología blockchain.

verificacion formal

Antes de sumergirse en las diferentes técnicas de verificación formal que están disponibles en el espacio blockchain,
Primero, desarrollemos un entendimiento de qué es la verificación formal, cuáles son sus tipos y
por qué es deseable.
Los métodos formales son el conjunto de técnicas utilizadas para modelar sistemas como objetos matemáticos. Estas
Los métodos incluyen la escritura de especificaciones en lógica formal, verificación de modelos, verificación y
pruebas. Generalmente, los métodos formales se pueden dividir en dos amplias disciplinas llamadas formales.
especificaciones y verificación formal. La primera disciplina se ocupa de la escritura precisa y
especificaciones concretas, mientras que este último engloba el desarrollo de pruebas para demostrar la
exactitud de una especificación.
Escalabilidad y otros desafíos
[728]
En esencia, la verificación formal consta de tres pasos:

  1. Primero, crear un modelo formal del sistema a verificar.
  2. En segundo lugar, escriba una especificación formal de las propiedades que se espera que se satisfagan
    por nuestro modelo.
  3. Finalmente, se verifica el modelo para asegurar que el modelo cumple con la especificación.
    Para verificar, hay dos categorías amplias de técnicas que se pueden utilizar, a saber, el estado
    enfoques basados ​​en exploración y enfoques basados ​​en pruebas. Ambos tienen ventajas y desventajas:
    • Los enfoques estatales basados ​​en la exploración son automáticos pero son ineficientes y difíciles de
    escala. Un problema habitual es la explosión de estados, donde el número de estados a comprobar crece tanto
    exponencialmente grande que el modelo no cabe en la memoria de una computadora.
    • Por otro lado, los enfoques basados ​​en pruebas (demostración de teoremas) son más precisos pero
    generalmente requieren interacción humana y un conocimiento más profundo de las pruebas y
    técnicas relevantes.
    En la siguiente sección, presentaremos una técnica de verificación formal llamada verificación de modelo, que
    se utiliza para comprobar la exactitud de un modelo de sistema.

La verificación basada en pruebas se realiza utilizando asistentes de prueba
como Coq:

https://coq.inria.fr/) and Isabelle (https://
isabelle.in.tum.de/

modelo de pruebas

La verificación de modelos se puede definir como una técnica utilizada para verificar automáticamente los sistemas de estados finitos.
El proceso subyacente se basa en ejecutar una búsqueda exhaustiva del espacio de estados del
sistema. Con este enfoque de fuerza bruta, se puede determinar si una especificación es verdadera o
falso. Esta opción se está volviendo más popular porque no requiere pruebas que consuman mucho tiempo.
escritura.
En cambio, este paradigma permite que un diseñador escriba la especificación formalmente y sus propiedades
y el verificador de modelos explorará automáticamente todo el espacio de estados y evaluará el modelo
contra las propiedades especificadas. Por ejemplo, si la especificación dice que un estado en particular
nunca debe alcanzarse y durante la exploración de estado, el comprobador de modelos encuentra que hay un
ejecución (seguimiento) que entra en ese mismo estado que no es deseable, entonces lo informará. los
El diseñador puede entonces abordar el problema en consecuencia.
La verificación basada en pruebas se realiza utilizando asistentes de prueba
como Coq (https://coq.inria.fr/) e Isabelle (https: //
isabelle.in.tum.de/).
Capítulo 21
[729]
En el siguiente diagrama se muestra una representación visual del proceso de verificación del modelo:

Modelo de pruebas

El proceso de verificación del modelo comienza con el modelado, donde se crea una especificación formal.
a partir de un diseño informal del modelo. El paso de especificación viene a continuación, cuando sea relevante
las propiedades del diseño se especifican utilizando algún formalismo lógico. Finalmente, la verificación de la
se lleva a cabo el modelo, que verifica todas las propiedades definidas en la especificación y proporciona
resultados. En el caso de resultados falsos o negativos, las trazas de error con contraejemplos (aproximadamente
definidas como excepciones) se proporcionan para ayudar al diseñador a rastrear el error.
Los lenguajes de afirmación matemática llamados lógicas temporales se utilizan para describir los estados de un sistema
tiempo extraordinario. La lógica temporal se utiliza en el paso de especificación del proceso de verificación del modelo, que
representa la evolución del comportamiento de un sistema a lo largo del tiempo, o en este caso, el orden de
eventos de un sistema a lo largo del tiempo. En este paradigma, una especificación de los comportamientos del sistema
a lo largo del tiempo se construye utilizando varias propiedades fundamentales de los estados individuales.
Por ejemplo, en un estado, se puede decir que “algo está encendido” o “algo está activo”. Existen
también conectores proposicionales utilizados en el diseño de la especificación, como AND ∧, OR ∨, NOT ¬, y
IMPLICAR ⇒. En breve utilizaremos estos conectores en algunos ejemplos básicos para demostrar cómo
se puede utilizar junto con fórmulas para describir las propiedades del sistema.
Por último, también existen conectivos temporales, que emiten declaraciones como “el sistema siempre puede
sólo tiene un proceso activo “, o” el sistema nunca puede estar en un estado en el que leer y escribir
las operaciones se realizan simultáneamente “.
Hay dos tipos de lógicas temporales, a saber, lógica temporal lineal (LTL) y computación.
lógica de árbol (CTL). LTL se ocupa de las propiedades del modelo en una única ruta de cálculo o
ejecución, mientras que CTL se utiliza para expresar propiedades en un árbol de todas las rutas posibles.
Escalabilidad y otros desafíos
[730]
Hay algunos operadores temporales fundamentales que se utilizan en LTL para describir el comportamiento de un sistema.
Estas propiedades se pueden utilizar para especificar las propiedades de seguridad y vitalidad de un sistema. los
Las fórmulas son ⃞ P (siempre), ◇ P (eventualmente), U (Hasta) y ◯ (Siguiente). El siempre y
eventualmente, las propiedades son las más utilizadas.
Por ejemplo, ⃞ ((Mensaje) ¬ firmado ∨ ¬ sellado) ⇒ ◯ ¬ válido) significa si un mensaje no está firmado
o sellado, siempre se da el caso de que el mensaje no sea válido. Otro ejemplo podría ser

((transmisión) ⇒ ◇ recibido), lo que significa que la transmisión siempre implica que eventualmente el mensaje
serán recibidos . Otro ejemplo general podría ser el de un horno microondas que garantiza que
la calefacción no debe comenzar hasta que la puerta esté cerrada, lo que puede representarse en lógica temporal como ¬
Puerta en U de calefacción (cerrada).
Se necesitan métodos formales para garantizar la seguridad de un sistema y se han utilizado en el
industrias de aviónica, electrónica, hardware y sistemas integrados durante bastante tiempo y, la mayoría
últimamente, en la industria del software. Debido al renovado interés en la investigación de sistemas distribuidos con
el advenimiento de blockchain, y varios incidentes de alto perfil que resultaron en pérdidas financieras, como
el infame truco DAO, la necesidad de utilizar métodos formales en el espacio blockchain se está volviendo
cada vez más prominente. Ya se han llevado a cabo algunas iniciativas; sin embargo, todavía queda un largo
camino a seguir.
Blockchain necesita aprovechar la investigación que ya se ha realizado en sistemas distribuidos
y espacio de verificación formal, de modo que no solo se puedan hacer más seguros los sistemas blockchain existentes,
pero se pueden desarrollar nuevas plataformas basadas en especificaciones formales. Cabe señalar que no
todos los aspectos de una cadena de bloques deben, o deberían, verificarse formalmente, debido al tiempo que consume
y naturaleza altamente involucrada del proceso de verificación. Por tanto, a veces es suficiente
Modele y pruebe las partes más críticas de una cadena de bloques, como los protocolos de consenso y seguridad.
Hay muchas dimensiones en una cadena de bloques donde la verificación y especificación del modelo usando
Las lógicas temporales pueden resultar muy útiles. Se puede usar para describir un aspecto de la cadena de bloques.
plataforma formalmente, que luego se puede verificar formalmente para garantizar que todas las propiedades requeridas
se cumplen. Por ejemplo, en el desarrollo de contratos inteligentes, independientemente del lenguaje utilizado, un
El modelo podría ser desarrollado y verificado antes de la codificación real del contrato inteligente. Esta
enfoque garantizará que el código del programa, si se programa correctamente de acuerdo con el
especificación, se comportará como está previsto. Como los contratos inteligentes se utilizan en todo tipo de usos críticos
casos, incluidas las transacciones financieras, es aconsejable aplicar la verificación de modelos en este dominio para
garantizar la equidad y seguridad del sistema.
Ahora, veremos brevemente cómo se pueden verificar los mecanismos de consenso.

verificando mecanismos de consenso

Desde otro ángulo, existe un mecanismo de consenso, como PBFT, en una cadena de bloques, que
asegura que todos los nodos de una red blockchain lleguen a un acuerdo sobre los valores propuestos,
incluso en presencia de nodos defectuosos.
Los mecanismos de consenso como PBFT y Raft se describieron en el capítulo
5, Algoritmos de consenso.
Se trata de un área de primordial importancia y, debido a su naturaleza crítica, se considera la más
mecanismo central vital de una cadena de bloques. La verificación de modelos puede desempeñar un papel crucial en el
descripción y verificación de algoritmos de consenso, para asegurar que los protocolos cumplen con
propiedades de seguridad requeridas.
Un enfoque general para verificar las propiedades de un algoritmo de consenso en blockchain comienza desde
especificar los requisitos, las propiedades requeridas y la especificación en un lenguaje formal.
Un algoritmo de consenso distribuido se evalúa contra dos categorías de propiedades de corrección,
a saber, seguridad y vitalidad. La seguridad generalmente significa que no pasará nada malo, mientras que
la viveza implica que algo bueno eventualmente ocurrirá. Ambas propiedades, entonces, tienen
algunas subpropiedades, según los requisitos. Por lo general, para los mecanismos de consenso,
tienen atributos de acuerdo, integridad y validez en las propiedades de seguridad y para la vivacidad, a menudo,
La terminación es una propiedad deseada.
Podemos decir que un programa es correcto si, en todas las ejecuciones posibles, el programa se comporta correctamente
según la especificación. La especificación se define formalmente, que luego se verifica utilizando
un verificador de modelos o probadores de teoremas.
El análisis estático nos permite comparar el código con un conjunto de reglas de codificación para encontrar defectos en el código. los
el código no se ejecuta; en cambio, se verifica estáticamente. Por otro lado, hay una dinámica
técnica de análisis donde el código se ejecuta para encontrar errores y se prueba con criterios de prueba.
El análisis dinámico generalmente constituye pruebas unitarias y no se considera una verificación formal
técnica. El análisis estático que utiliza técnicas formales se utiliza para verificar formalmente la corrección de
el programa.
Con esto, hemos completado nuestra introducción básica a la verificación formal. Ahora, echemos un vistazo
en seguridad de contrato inteligente y vea qué herramientas formales están disponibles para la seguridad de contrato inteligente
verificación.

Hay varias opciones disponibles para modelar y verificar programas,
pero herramientas como TLA + y TLC model checker están haciendo que los procesos
más accesibles, y están ganando protagonismo en este espacio. Otro
herramienta popular se conoce como SPIN, que utiliza PROMELA para escribir
especificaciones. Sin embargo, tenga en cuenta que no existe una única respuesta correcta: la
La elección de las herramientas formales de verificación depende principalmente del juicio y
experiencia del diseñador, el tipo y profundidad de verificación requerida,
y, hasta cierto punto, la usabilidad de las herramientas de verificación.

seguridad de los contratos inteligentes

Recientemente, se ha comenzado a trabajar mucho en la seguridad de los contratos inteligentes y, especialmente, en el
La verificación de contratos inteligentes se está discutiendo e investigando. Todo esto fue provocado
especialmente debido al infame truco DAO.
La verificación formal es un proceso de verificación de un programa de computadora para asegurarse de que cumple
ciertas declaraciones formales. Este no es un concepto nuevo y hay varias herramientas disponibles para
otros lenguajes que logran esto; por ejemplo, Frama-C (https://frama-c.com) está disponible para
analizando programas C.
Hay varias opciones disponibles para modelar y verificar programas,
pero herramientas como TLA + y TLC model checker están haciendo que los procesos
más accesibles, y están ganando protagonismo en este espacio. Otro
herramienta popular se conoce como SPIN, que utiliza PROMELA para escribir
especificaciones. Sin embargo, tenga en cuenta que no existe una única respuesta correcta: la
La elección de las herramientas formales de verificación depende principalmente del juicio y
experiencia del diseñador, el tipo y profundidad de verificación requerida,
y, hasta cierto punto, la usabilidad de las herramientas de verificación.
Escalabilidad y otros desafíos
[732]
La idea clave detrás de la verificación formal es convertir el programa fuente en un conjunto de declaraciones
eso es comprensible para los probadores automatizados. Para ello, Why3, que es una plataforma
para la verificación del programa, se usa comúnmente. Analizaremos Why3 en detalle en el tema Why3,
más adelante en esta sección.
La seguridad de los contratos inteligentes es de suma importancia ahora, y muchas otras iniciativas también han
se han tomado para idear métodos que puedan analizar los programas de Solidity y encontrar errores. UN
Un ejemplo reciente y fundamental es Oyente, que es una herramienta construida por investigadores para analizar
Contratos.
Se han descubierto y analizado varios errores de seguridad en contratos inteligentes en el Oyente
libro blanco, Cómo hacer que los contratos inteligentes sean más inteligentes. Estos incluyen la dependencia de pedidos de transacciones,
dependencia de la marca de tiempo, excepciones mal manejadas como explotación del límite de profundidad de la pila de llamadas,
y vulnerabilidad de reentrada. El error de dependencia de pedidos de transacciones básicamente explota el
escenarios en los que el estado percibido de un contrato podría no ser el estado del contrato
cambia a después de la ejecución.
Esta debilidad es un tipo de condición de carrera. También se llama frontrunning y es posible debido a la
hecho de que se puede manipular el orden de las transacciones dentro de un bloque. Como todas las transacciones primero
aparecen en el grupo de memoria, las transacciones allí se pueden monitorear antes de que se incluyan en
el bloque. Esto permite que una transacción se envíe antes que otra transacción, lo que lleva a
controlando el comportamiento de un contrato inteligente.
Los errores de dependencia de la marca de tiempo son posibles en escenarios donde se usa la marca de tiempo del bloque
como una fuente de toma de decisiones dentro del contrato, pero las marcas de tiempo se pueden manipular
por los mineros. El límite de profundidad de la pila de llamadas es otro error que se puede aprovechar debido al hecho de que
la profundidad máxima de la pila de llamadas de EVM es 1.024 tramas. Si se alcanza la profundidad de la pila mientras
contrato se está ejecutando, entonces, en ciertos escenarios, la instrucción de envío o llamada puede fallar, lo que resulta en
impago de fondos.

Tenga en cuenta que un verificador Why3 experimental pero operativo estaba disponible en
Remix IDE inicialmente, pero luego se eliminó. Sin embargo, ahora, en el Remix
IDE, opciones de análisis estático están disponibles. Detalles pueden ser encontrados aqui:

https://remix-ide.readthedocs.io/en/latest/static_analysis.html

También presentaremos un ejemplo de análisis estático en el Remix IDE en el
Siguiente sección

El error de profundidad de la pila de llamadas se abordó en el hard fork del EIP 50 en:

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-150.md.

analisis estatico en el ide remix

El análisis estático del código de Solidity ahora está disponible como una función en el IDE Remix en línea de Solidity.
El código se analiza en busca de vulnerabilidades y se informa en la pestaña de análisis de Remix IDE:

Opciones Remix

Una salida de muestra de un contrato con error de reentrada se muestra en la parte inferior de la anterior
captura de pantalla.
El análisis estático en Remix IDE analiza varias categorías de vulnerabilidades, incluida la seguridad
y Gas y Economía. Como se muestra en la captura de pantalla anterior, la herramienta de análisis ha
detectó el error de reentrada, cuyos detalles se muestran en la parte inferior de la pantalla.
Además de las capacidades de análisis estático dentro de Remix IDE, también hay otras herramientas disponibles, como
como Why3, que discutiremos a continuación.

why3

Why3 también se puede utilizar para analizar formalmente el código de Solidity.
En el siguiente ejemplo, un fragmento simple de código de Solidity que define la variable z como el
se muestra el límite máximo de uint. Cuando este código se ejecuta, devolverá 0,
porque uint z invadirá y comenzará de nuevo desde 0. Esto también se puede verificar usando Why3, que
se muestra aquí:

Verificacion formal

Why3 está disponible en http://why3.lri.fr/try/.

La conversión de Solidity al código compatible con Why3 solía estar disponible en el sitio en línea de Solidity.
compilador, pero ya no está disponible. Por lo tanto, el siguiente ejemplo es solo para completar
propósitos y arrojar luz sobre una clase importante de errores que pueden pasar desapercibidos con los
herramientas. En este ejemplo, el desbordamiento de enteros se muestra como ejemplo.
El siguiente ejemplo muestra que Why3 verifica e informa correctamente el desbordamiento de enteros
errores. Esta herramienta está en un gran desarrollo, pero sigue siendo bastante útil. Además, cabe señalar
esa herramienta, o cualquier otra herramienta similar, no es una panacea. Incluso la verificación formal en general
no debe considerarse una panacea. Esto se debe a que las especificaciones en primer lugar deben
definido apropiadamente:

Why3 analizado un smart contract

En la captura de pantalla anterior, el IDE Why3 se muestra con un contrato inteligente que se analiza para
problemas, que se informan en el lado derecho. En este caso, se ha producido un desbordamiento de enteros.
encontrado, que se informa.
En la siguiente sección, veremos cómo se puede utilizar una herramienta diferente, Oyente, para probar un contrato inteligente para
vulnerabilidades de seguridad.

oyente

Actualmente, Oyente está disponible como una imagen de Docker para una fácil instalación y prueba. Está disponible
en https://github.com/melonproject/oyente y se puede descargar y probar.
En el siguiente ejemplo, un simple contrato tomado de la documentación de Solidity que contiene
Se ha probado un error de reentrada. Primero, mostraremos el código con un error de reentrada:

Contrato con un bug de tipo reentrada

Este código de muestra contiene un error de reentrada, que básicamente significa que si un contrato es
interactuando con otro contrato o transfiriendo éter, está efectivamente entregando el control
a ese otro contrato. Esto permite que el contrato llamado vuelva a llamar a la función del contrato.
de donde ha sido llamado, sin esperar su finalización. Por ejemplo, este error puede permitir
volver a llamar a la función de retirada que se muestra en el ejemplo anterior una y otra vez,
resultando en la obtención de ETH varias veces. Esto es posible porque el valor de la acción no está establecido en 0
hasta el final de la función, lo que significa que cualquier invocación posterior tendrá éxito, lo que
en retirarse una y otra vez.
Se muestra un ejemplo de Oyente corriendo para analizar el contrato que se muestra aquí y, como puede ser
visto en el siguiente resultado, el análisis ha encontrado con éxito el error de reentrada. El error es
propuesto para ser manejado por una combinación del patrón de Verificaciones-Efectos-Interacciones descrito en
la documentación de Solidez:

Oyente detectando bugs

Oyente también está disponible en las herramientas de análisis para contratos inteligentes en https: //oyente.melonport.
com. Aquí se muestra un resultado de muestra:

Analisis Oyente

Con este ejemplo, concluimos nuestra introducción a las herramientas de análisis y seguridad para Solidity. Esta
es un área de investigación muy rica y, con el tiempo, se espera que haya más herramientas disponibles.
Hay muchos expertos e investigadores en la academia y el sector comercial que exploran
esta área y pronto, habrá muchas herramientas automatizadas disponibles para la verificación de
Contratos. Ya hay una herramienta en línea disponible en https://securify.ch que analiza
código de contrato para encontrar vulnerabilidades de seguridad.
Ahora, analizaremos algunas otras herramientas que podemos usar para analizar la corrección de los contratos inteligentes.
y vulnerabilidades de seguridad.

otras herramientas

Otras herramientas e investigaciones relevantes en el campo de la seguridad de la tecnología blockchain incluyen
Solgraph, Manticore y otras herramientas para la verificación formal de contratos inteligentes.

solgrafh

Esta herramienta genera un gráfico de flujo de control de funciones de un contrato de solidez y encuentra posibles
vulnerabilidades de seguridad. Más información sobre esta herramienta está disponible aquí: https://github.com/
raineorshine / solgraph

manticore

Este es un marco de ejecución simbólico que se puede utilizar para binarios y contratos inteligentes.
La ejecución simbólica es un método utilizado para analizar programas de computadora para determinar qué parte de
el programa de computadora se ejecuta como resultado de qué entrada. En otras palabras, establece qué
input ejecuta qué parte del programa. En ejecución simbólica, en lugar de datos de entrada reales,
Se utilizan valores simbólicos, que luego se utilizan para evaluar el programa. Además, un automatizado
El demostrador de teoremas se utiliza para comprobar si hay valores que dan como resultado un comportamiento incorrecto del
programa o provocar que falle. Se utiliza para depuración, pruebas de software y seguridad.

Puede encontrar más información sobre Manticore aquí:

Mossberg, M., Manzano, F., Hennenfent, E., Groce, A., Grieco, G., Feist, J.,
Brunson, T. and Dinaburg, A., 2019, November. Manticore: A user-friendly
symbolic execution framework for binaries and smart contracts. In 2019 34th
IEEE/ACM International Conference on Automated Software Engineering
(ASE) (pp. 1186-1189). IEEE. https://arxiv.org/pdf/1907.03890.

verificacion formal de contratos inteligentes

También se han realizado muchas investigaciones sobre la verificación formal de contratos inteligentes.
Las técnicas propuestas incluyen, pero no se limitan a, verificación de modelos, análisis estático,
análisis dinámico y verificación mediante asistentes de prueba.
Algunos de los artículos más relevantes sobre el tema incluyen los siguientes:

• Nehai, Z., Piriou, P.Y. and Daumas, F., 2018, July. Model-checking of smart contracts. In
2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green
Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social
Computing (CPSCom) and IEEE Smart Data (SmartData) (pp. 980-987). IEEE. https://
hal.archives-ouvertes.fr/hal-02103511/file/Nehai-Piriou-Daumas%20V18_03_09.pdf .


• Bang, T., Nguyen, H.H., Nguyen, D., Trieu, T. and Quan, T., 2020. Verification of Ethereum
Smart Contracts: A Model Checking Approach. International Journal of Machine Learning
and Computing, 10(4). http://www.ijmlc.org/vol10/977-AM0059.pdf .
• Antonino, P. and Roscoe, A.W., 2020. Formalising and verifying smart contracts with
Solidifier: a bounded model checker for Solidity. arXiv preprint arXiv:2002.02710. https://
arxiv.org/pdf/2002.02710 .

• Kalra, S., Goel, S., Dhawan, M. and Sharma, S., 2018, February. ZEUS: Analyzing Safety of
Smart Contracts. In NDSS. http://pages.cpsc.ucalgary.ca/~joel.reardon/blockchain/
readings/ndss2018_09-1_Kalra_paper.pdf .


• Amani, S., Bégel, M., Bortin, M. and Staples, M., 2018, January. Towards verifying
Ethereum smart contract bytecode in Isabelle/HOL. In Proceedings of the 7th ACM
SIGPLAN International Conference on Certified Programs and Proofs (pp. 66-77).
https://dl.acm.org/doi/pdf/10.1145/3167084 .
More information on Manticore can be found here:
Mossberg, M., Manzano, F., Hennenfent, E., Groce, A., Grieco, G., Feist, J.,
Brunson, T. and Dinaburg, A., 2019, November. Manticore: A user-friendly
symbolic execution framework for binaries and smart contracts. In 2019 34th
IEEE/ACM International Conference on Automated Software Engineering
(ASE) (pp. 1186-1189). IEEE. https://arxiv.org/pdf/1907.03890.


• Chen, X., Park, D. and Roşu, G., 2018, November. A language-independent approach to
smart contract verification. In International Symposium on Leveraging Applications of
Formal Methods (pp. 405-413). Springer, Cham. http://fsl.cs.illinois.edu/FSL/
papers/2018/chen-park-rosu-2018-isola/chen-park-rosu-2018-isola-public.pdf

Después de toda esta discusión sobre la seguridad de los contratos inteligentes, ahora deberíamos entender su importancia.
Si bien todos los problemas y técnicas discutidos aquí para mitigar los problemas de seguridad en smart
los contratos son valiosos, todavía surge una pregunta sobre qué más podemos hacer, dado que
La seguridad de los contratos es un tema delicado que puede provocar graves pérdidas económicas. La respuesta podría
sea ​​que tratamos los contratos inteligentes y la cadena de bloques subyacente como sistemas críticos para la seguridad, y
luego aplique todos los atributos de los sistemas críticos para la seguridad a los contratos inteligentes. De una ingeniería
perspectiva, se convertirá en un tema de sistemas críticos para la seguridad y será tratado como tal.
Esta idea puede parecer un poco exagerada, pero imagina si, algún día, un contrato inteligente es el responsable
por generar un evento que desencadenaría un apagado como resultado del sobrecalentamiento en una
reactor. De nuevo, quizás un poco exagerado, pero totalmente posible: con IoT y blockchain
convergencia tales escenarios podrían convertirse en una realidad, donde los reactores nucleares están funcionando usando un
blockchain como mecanismo para controlar y rastrear operaciones asociadas.
Ahora, presentaremos algunos otros desafíos que enfrenta la tecnología blockchain, que deberían ser
resuelto para permitir la adopción generalizada de blockchain.

La seguridad de los contratos inteligentes es un área de investigación muy interesante y extensa. Es
casi imposible cubrir todos los aspectos en este breve capítulo. Usted está
Animamos a leer la introducción a la verificación formal anteriormente en este
capítulo y luego revise algunos de los artículos anteriores para obtener más
investigación.

otros desafios

Además de cuestiones clave como la privacidad y la escalabilidad, existen algunos otros desafíos
que puede obstaculizar la adopción de blockchain como tecnología convencional. Discutiremos estos
desafíos y algunas posibles soluciones a continuación.

interoperabilidad

Discutimos la interoperabilidad brevemente anteriormente en este libro. Basta decir aquí que
La interoperabilidad es un desafío abierto y aunque muchas iniciativas como Cosmos, Polkadot y
Interledger está en proceso de abordar esta limitación, todavía queda un largo camino por recorrer. Uno de los
enfoques es la estandarización de los protocolos de blockchain, haciéndolos compatibles con uno
otro. Otro enfoque es desarrollar protocolos que hagan interactuar las cadenas de bloques existentes.
entre sí, tal Interledger.
Cubrimos Cosmos e Interledger en detalle en las páginas de contenido adicional de este libro, aquí:

En esta sección, describiremos brevemente Polkadot.

polkadot

Polkadot es una plataforma que permite la conectividad entre diferentes cadenas públicas y privadas,
oráculos y muchas otras tecnologías. Es una plataforma que se utiliza para habilitar Web3, una
web, y permite intercambiar cualquier tipo de datos entre cualquier tipo de blockchain. Ofrece
fragmentación heterogénea, escalabilidad, capacidad de actualización, gobernanza transparente y cadena cruzada
composibilidad.
El concepto clave detrás de Polkadot es una cadena de relés, que es responsable de la cadena cruzada.
interoperabilidad, consenso y seguridad general de la red. Polkadot permite la comunicación
entre diferentes fragmentos independientes de blockchain llamados paracaídas. Las paracaídas se conectan a
la cadena de relés después de pagar una tarifa. Otros componentes incluyen puentes, que son un tipo especial de
blockchain que permite la conectividad de paracaídas con redes externas como Bitcoin y
Ethereum.
Desde una perspectiva de consenso, hay varios elementos en Polkadot. Los validadores aseguran el
encadenar apostando tokens llamados DOT. Los DOT proporcionan gobernanza, participación y vinculación. PUNTO
los titulares pueden participar en actividades de gobernanza, como actualizaciones de protocolos. Replanteo
with DOTs proporciona un mecanismo para garantizar la seguridad y estabilidad de la red Polkadot.
Además, la vinculación mediante DOT permite agregar nuevas paracaídas a la red. En general, en
la red Polkadot, los validadores aseguran la cadena y son seleccionados por los nominadores debido a su
integridad. Los intercaladores mantienen fragmentos y los llamados pescadores operan en la red durante
fines de vigilancia y vigilancia.

Más detalles sobre Polkadot están disponibles aquí:

https://polkadot.network/.

carencia de estandarizacion

La falta de estandarización conduce a sistemas dispares que no pueden comunicarse con cada uno.
otro. Esto conduce a problemas de interoperabilidad. Por lo tanto, es necesario desarrollar un
comprensión de los requisitos para desarrollar plataformas blockchain para el mismo
estándar. Hacer esto asegurará que todas las plataformas sean interoperables.

resistencia post-cuantica

Con la llegada de las computadoras cuánticas, se prevé que, pronto, la criptografía utilizada en
blockchain correrá el riesgo de volverse menos seguro. Esto se debe a la capacidad de los
computadoras para trabajar a una velocidad fenomenal, lo que permite el criptoanálisis de la mayoría de los esquemas
actualmente en uso. Ya se está trabajando para proteger las cadenas de bloques contra
ataques post-cuánticos, pero todavía queda mucho por hacer.
Más detalles sobre Polkadot están disponibles aquí: https: // polkadot.
red/.
Ethereum 2.0 también se asegura de que la criptografía elegida sea cuántica segura o
conectable con contrapartes de seguridad cuántica cuando estén disponibles.
Además, los esquemas de firma resistentes a los cuánticos, como el Esquema de firma extendido de Markle
(XMSS) y SPHINCS están siendo investigados para Ethereum 2.0. El RANDAO de la cadena de balizas es
también se espera que sea resistente a los cuánticos.

Algunas de las soluciones propuestas se enumeran aquí:
El libro mayor de resistencia cuántica se puede encontrar en: https://www.theqrl.org.
Además, se están realizando esfuerzos del NIST, que se pueden explorar aquí:

https://csrc.nist.gov/Projects/post-quantum-cryptography/Post-Quantum-Cryptography-Standardization.

Un artículo que explora la seguridad cuántica para Ethereum 2.0 está disponible aquí:

https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/.

regulaciones y cumplimientos

El cumplimiento y la regulación son aspectos importantes. En los sistemas de TI tradicionales, el cumplimiento y
La regulación juega un papel vital para garantizar que los datos y la información se manejen de acuerdo
con las políticas, reglas y estándares establecidos por las autoridades reguladoras. Adherirse a tales estándares
minimiza la posibilidad de violaciones de seguridad, acceso no autorizado a los datos y otros problemas
derivados del manejo inadecuado de los datos. Ahora, blockchain puede, de hecho, ayudar a lograr
Cumplimiento de ciertas regulaciones, como GDPR y otros casos de uso, donde la manipulación es resistente
Se requiere la auditoría de registros.
Ya se ha trabajado mucho en el contexto de las criptomonedas y los tokens, pero no tanto
mucho desde la perspectiva de blockchain subyacente. Tratar las criptomonedas y los tokens como
valores (permitir que se rijan por las leyes de valores existentes) es una cosa, pero regular
la tecnología blockchain subyacente en términos de adherencia a los estándares de seguridad, datos
la soberanía y las regulaciones para compartir información es otra. Discutimos el cumplimiento en detalle
en el Capítulo 20, Enterprise Blockchains.
Con esto, hemos completado nuestro examen de los diferentes desafíos a los que se enfrenta blockchain, y
También discutió algunas de las soluciones actuales disponibles para abordar estos desafíos durante el
próximas etapas de la evolución de blockchain.

resumen

En este capítulo, presentamos los diversos desafíos que enfrenta la tecnología blockchain. La mayor
desafío, la escalabilidad limitada de blockchain, se discutió, junto con varios métodos disponibles
para lograr una mayor escalabilidad. Abordamos estos métodos utilizando diferentes modelos, que
Divida la cadena de bloques en planos o capas que se pueden mejorar de diferentes maneras.
También discutimos la privacidad, que es uno de los principales factores limitantes para la adopción de
blockchains para varios casos de uso empresarial. A continuación, exploramos la seguridad de los contratos inteligentes y
varias herramientas para mejorarlo, como la verificación de modelos. La verificación formal es una profunda y extensa
tema, pero se brindó una breve introducción a varios aspectos, que debe servir como
terreno para futuras investigaciones en esta área. También vimos ejemplos de verificación formal para tener un
idea de las herramientas disponibles.
Finalmente, discutimos algunos otros desafíos a considerar para el futuro de blockchain, que incluyen
la cuestión de la estandarización y la capacidad de conexión, y la inevitable necesidad de resistencia cuántica.
En el próximo y último capítulo de este libro, exploraremos el panorama actual y el futuro
perspectivas de la tecnología blockchain.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s