Muchas plataformas de contratos inteligentes (como Ethereum 2.0, Polkadot, Dfinity, Near Protocol, Algorand, Kadena, Spacemesh y Solana) se lanzarán a lo largo del próximo año o dos. Cada equipo está buscando una estrategia de escalamiento única.
Sin embargo, la mayoría de esos enfoques no soluciona uno de los problemas fundamentales de los sistemas de computación distribuidos en entornos bizantinos: el problema del reloj. Para llegar a un consenso, al menos el 51 % de las máquinas de la red deben ejecutar las mismas transacciones en el mismo orden y al mismo tiempo. Para hacerlo, las máquinas deben ponerse de acuerdo en el uso de un reloj global. El “problema del reloj” es el desafío de conseguir que muchas máquinas desconfiadas se pongan de acuerdo para usar un mismo reloj global en los ajustes bizantinos. Cuando todos están de acuerdo en un reloj global, el ordenamiento de transacciones se convierte en un problema mucho más simple, ya que cada transacción queda marcada con la hora según el mismo reloj global.
El problema del reloj ya se ha manifestado en otras redes a gran escala antes de la era de las criptomonedas modernas, principalmente en el mundo de las comunicaciones inalámbricas. Las torres celulares deben admitir decenas de miles de teléfonos celulares a la vez. No había suficiente ancho de banda como para darle a cada teléfono su propia radiofrecuencia, por lo que las telecomunicaciones necesitaban “tecnologías de acceso múltiple" para incluir múltiples llamadas telefónicas en la misma frecuencia.
El Acceso múltiple por división de código (CDMA) se inventó durante la Segunda Guerra Mundial. Para hacerle frente al problema del reloj, el CDMA requiere que cada teléfono encripte sus datos con una clave única y transmita a través de varias frecuencias al mismo tiempo que otros teléfonos, dependiendo de que la torre celular divida la señal combinada en sus llamadas individuales. La eficiencia de este esquema mejora a una velocidad directamente proporcional a la complejidad del esquema de encriptación. Históricamente, en redes ampliamente disponibles que deben admitir dispositivos finales baratos, esta tasa de mejora ha sido lenta y constante.
Las empresas de telecomunicaciones han ganado eficiencia mucho más rápido mediante la implementación del Acceso múltiple por división de tiempo (TDMA), que se ha convertido en la solución estándar para hacerle frente al problema del reloj desde el advenimiento de las redes celulares 2G. El TDMA hace que las torres dividan cada radiofrecuencia en franjas horarias y asignen esas franjas horarias a cada llamada telefónica. De esa manera, la torre celular proporciona un reloj disponible a nivel mundial para la red. Eso aumenta enormemente la escalabilidad del ancho de banda limitado, pues permite que cada frecuencia admita canales de datos múltiples simultáneos y disminuya la interferencia de múltiples teléfonos que transmiten en la misma frecuencia al mismo tiempo.
En este ensayo, exploraré la manera en que diferentes cadenas de bloques manejan el problema del tiempo en los ajustes bizantinos. Concluiré argumentando que la cadena de bloques que construya el reloj más efectivo separará con éxito el tiempo del estado y podrá escalar para admitir el rendimiento de millones de usuarios de manera segura y descentralizada.
Consenso descentralizado con un reloj
La base de datos Spanner de Google es una de las bases de datos distribuidas a nivel global más eficientes del mundo, con 18 instancias que procesan transacciones de manera simultánea. Admite más de 50 000 transacciones por segundo (TPS) con un tiempo de compleción (TTF) inferior a un segundo. Spanner usa el algoritmo de consenso de Paxos, que se publicó por primera vez en 1989. Spanner es una base de datos de confianza que usa permisos. Paxos permite que Spanner siga funcionando a pesar de cortes de energía, fallas del servidor, virus malignos y muchas otras fallas.
¿Cómo logra Paxos tal rendimiento cuando la cadena de bloques de mayor rendimiento hoy en día apenas alcanza las más de 5000 transacciones por segundo con tan solo 21 instancias? Google contrata ingenieros a tiempo completo para que estén in situ y sincronicen periódicamente y de manera muy precisa los relojes atómicos en cada centro de datos. Ofrecer un reloj de confianza disponible a nivel mundial permite marcar la hora exacta de las transacciones para que cada instancia pueda recibir transacciones desordenadas, pero procesarlas en el orden correcto. Esto equivale a una separación de tiempo y estado, ya que cada instancia actualiza su estado sin tener que comprobar con sus pares para asegurarse de que están realizando las mismas acciones en el mismo orden.
¿Qué podemos aprender de Spanner? Si hay un reloj disponible a nivel mundial en un entorno no bizantino, llegar al consenso es muy fácil. Desafortunadamente, las plataformas de contratos inteligentes actuales tienen dos restricciones adicionales que no existen en Spanner:
- Convertirse en validador no puede requerir permisos, pues, de otro modo, la plataforma no podría resistir la censura
- Las cadenas de bloques deben mantener seguros los fondos de los usuarios incluso si hasta un una tercera parte de los validadores son malignos
Si cualquier persona puede generar una instancia de validación en cualquier parte del mundo, los algoritmos de consenso deben estar diseñados para aceptar diferentes configuraciones de hardware y de red, y deben poder hacerle frente a la presencia de validadores malignos. Además, para que sean realmente resistentes a la censura, no se puede confiar en ninguna información fuera de banda (lo cual se conoce también como el problema del oráculo)
Veinte años después de la invención de Paxos, alguien descubrió cómo conseguir que una red de computadoras sin permisos llegara al consenso sobre un ordenamiento canónico de transacciones. Ese alguien fue Satoshi Nakamoto y la solución fue el consenso de Prueba de Trabajo (PoW, por sus siglas en inglés).
Prueba de trabajo (PoW) + Cadena de tiempo = Reloj
No es casual que el código de Bitcoin previo al lanzamiento de Satoshi llamara "cadena de tiempo" a la estructura ya familiar de estructura de datos de la cadena de bloques. Esta cadena de tiempo está diseñada para avanzar un punto cada 10 minutos en promedio (por medio de una ingeniosa maraña de Pruebas de Trabajo, ajustes de dificultad y de la regla de la cadena más larga, la cual está fuera del alcance de este ensayo), donde cada punto viene en la forma de un bloque de transacciones que actualizan el estado global. Después de que un nodo ejecuta un bloque de transacciones, cualquier actualización de estado queda bloqueada hasta que produzca un nuevo bloque válido propio o reciba un nuevo bloque válido de la red. En la PoW, el tiempo y el estado están acoplados y funcionan siempre al unísono. El tiempo no puede avanzar sin una actualización al estado.
Lo que hace que un bloque sea “válido” es un tema muy debatido. Los formatos de las transacciones y el tamaño de los bloques son solo dos de los muchos factores que se tienen en cuenta. Sin embargo, un aspecto de un bloque válido que no está sujeto a discusión es que el mismo debe contener el hash de un bloque anterior para que la red sepa ponerlo después de ese bloque anterior en la cadena de tiempo.
Imagen: En una cadena de bloques, cada bloque incluye el hash del bloque anterior como prueba de que siguió después.
El objetivo de la cadena de tiempo es abordar el mencionado requisito #2: convertirse en validador no debe requerir permisos. La única manera de validar que el estado actual de la red de Bitcoin es válido es comenzar desde el estado del bloque inicial y ejecutar todas las transacciones desde ese génesis hasta el estado actual. La cadena de tiempo proporciona el rastro de auditoría para que un nuevo validador siga demostrando que las transacciones del bloque a la altura 12 se produjeron y deben ser ejecutadas después de las transacciones del bloque a la altura 11. Dado que el bloque 12 tiene que incluir el hash del bloque 11, el bloque 12 solo pudo haber sido creado después del bloque 11. Esta cadena de tiempo de hashes produce un reloj lógico, monotónico (aunque irregular y no muy detallado) que cualquier validador de la red puede verificar de forma independiente sin recurrir a ninguna información fuera de banda.
Producir ese reloj de confianza disponible a nivel mundial en un entorno abierto y sin permisos fue la mayor innovación de Satoshi. Dado que el estado global queda bloqueado hasta que el reloj global vuelva a avanzar con un nuevo bloque, el cálculo de la escalabilidad es simple:
Rendimiento [transacciones por segundo] = Tamaño de bloque [transacciones por bloque] / Tiempo del bloque [segundos por bloque]
Para aumentar el rendimiento, el protocolo debe aumentar el tamaño del bloque o disminuir su duración. Aumentar el tamaño del bloque perjudica la descentralización de los productores de bloques y disminuir su duración aumenta la probabilidad de bifurcaciones de la cadena.
Dado que el tiempo y el estado están acoplados, no hay manera de evitar esto.
Volviendo al ejemplo de las comunicaciones inalámbricas, comparemos este problema con el CDMA. En el CDMA, las torres de radio tienen un ancho de banda fijo de frecuencias que pueden escuchar, lo que es análogo a cómo los productores de bloque tienen un tamaño fijo de bloque que pueden procesar. Aumentar la escalabilidad en el CDMA significa crear esquemas de codificación más complicados para que quepan más llamadas telefónicas dentro de ese ancho de banda limitado. Eso es análogo a los Segwit, a los canales Lightning y a las firmas Schnorr, que son esquemas de codificación más complejos que permiten un mejor rendimiento.
El Bitcoin tiene 1 MB de bloques, un tiempo de bloque de 600 segundos y un tamaño de transacción mínimo de 250 B, lo que equivale a un rendimiento máximo teórico de 7 transacciones por segundo. Es decir aproximadamente 7000 veces menos rendimiento y un tiempo de compleción 3600 veces más lento que Spanner (ya que se necesitan 6 tiempos de bloque para lograr una compleción probabilísticamente irreversible).
Claramente, se podría mejorar.
Prueba de participación + Cadena de tiempo = Reloj más rápido
El crecimiento del Bitcoin provocó un renacimiento en la investigación de los algoritmos de consenso. El Teorema de CAP nos dice que, en el caso de una partición de la red, un sistema de base de datos distribuido debe elegir entre la consistencia (un punto de confluencia en la red) y la disponibilidad (una bifurcación en la red). El algoritmo de Satoshi fue el primer algoritmo de consenso BFT sin permisos de la familia del Consenso de Nakamoto, que elige la disponibilidad sobre la consistencia. Hay muchos algoritmos de consenso en la familia de Nakamoto.
El algoritmo de Paxos de Leslie Lamport fue el primero de la familia del Consenso Clásico que prefirió la consistencia sobre la disponibilidad.
En Paxos, y en muchos otros algoritmos de la familia del Consenso Clásico, cada nodo participante en el consenso debe comunicarse sincrónicamente con todos los demás validadores de la red para cada actualización de estado. Eso hace que la complejidad de la comunicación sea O(n^2) (donde n es el conteo de validadores), lo que significa que el tiempo requerido entre cada actualización de estado aumenta exponencialmente a medida que el conteo de validadores aumenta.
Ethan Buchman y Jae Kwon fueron los primeros que tomaron los 20 años de investigación sobre el Consenso Clásico acumulados y la impregnaron de una estructura de incentivos criptoeconómicos llamada Prueba de participación garantizada (BPoS, por sus siglas en inglés) para limitar de forma segura el conteo de validadores. El resultado de su trabajo fue el primer algoritmo de consenso BFT funcional sin permisos de la familia del Consenso Clásico: Tendermint.
Al igual que el consenso de Nakamoto, Tendermint agrupa las actualizaciones de tiempo y estado, por lo que su rendimiento solo aumenta cuando aumenta el tamaño del bloque o cuando el tiempo de bloque disminuye. Cuando el Bitcoin fue inventado en 2009, un tiempo de bloque de 10 minutos era razonable. Sin embargo, el ancho de banda ha crecido exponencialmente desde entonces, permitiendo que las cadenas de Tendermint reduzcan los tiempos de bloque a apenas unos segundos.
Dado que las bifurcaciones son imposibles porque Tendermint prefiere la consistencia, el tiempo de bloque se puede reducir hasta que los límites del rendimiento de la red provoquen un atasco en el sistema para un conteo de validadores determinado. Hoy en día, Tendermint le permite a la red limitar de forma segura su conteo de validadores a 100, lo que produce el agradable beneficio de filtrar nodos con un ancho de banda deficiente y permitir tamaños de bloque más grandes.
Tendermint está en producción. El Hub Cosmos (la primera instancia en vivo de Tendermint) se está ejecutando en un tiempo de bloque de 6 segundos con bloques de 150 kB, lo que permite un rendimiento máximo de 100 transacciones por segundo (asumiendo que se manejan transacciones de 250 bytes). Sin embargo, tiene apenas meses de nacido y va a madurar rápidamente. Teóricamente, una red Tendermint con tiempos de bloque de 5 segundos y bloques de 5 MB podría alcanzar las 4000 transacciones por segundo con sacrificios mínimos en la resistencia a la censura y la ausencia de permisos en comparación con el Bitcoin. ¡Eso representaría un aumento de 570 veces en el rendimiento y una disminución de 720 veces en el tiempo de compleción!
Desafortunadamente, debido a la naturaleza sincrónica de los algoritmos de Consenso Clásico, igualar a Spanner afectaría negativamente las propiedades de resistencia a la censura y de operación sin permisos del sistema. Inevitablemente, los bloques más grandes tardarán más en propagarse por la red y los validadores tardarán más en verificarlos, lo cual le pone un límite a qué tanto pueden bajar los tiempos de bloque. Para aumentar la velocidad del reloj, el número de validadores tendría que disminuir significativamente y todos tendrían que estar conectados directamente a la misma red de fibra. Eso aumentaría tanto el potencial de conspiración entre validadores como la barrera de entrada para nuevos validadores. Además, convertiría al operador de la red de fibra en un punto de centralización.
El siguiente paso importante en la evolución del consenso de la cadena de bloques consistiría en separar tiempo y estado, lo cual permitiría un gran aumento del rendimiento, pero a un costo bastante alto.
Fragmentación + Cadena de tiempo = Relojes independientes
Con las BPoS, Tendermint separó la resistencia a la censura del número de validadores, lo cual permitió que el reloj de la red pasara de avanzar cada 600 segundos a hacerlo cada 5, abriéndole la puerta a una gran mejora de rendimiento. Sin embargo, entre cada avance del reloj, el estado global entero sigue quedando bloqueado a fin de mantener un estado congruente a nivel global.
Una manera de mitigar ese problema es dividiendo el estado global en un montón de pedazos más pequeños, cada uno con su propio reloj independiente que puede avanzar de manera independiente. Mientras esos fragmentos no tengan que interactuar entre sí, el desempeño de cada uno no cambia y el rendimiento sumado de todos los fragmentos aumenta de forma lineal con respecto al número de fragmentos.
Cosmos concibe muchas redes independientes de cadena de bloques que existen paralelamente, que pueden transferir valor entre ellas pero haciendo transacciones principalmente al interior de sus propios sistemas. Si cada red puede procesar 4000 transacciones por segundo y hay 13 redes, ¡el sistema en su conjunto puede superar a Spanner con un rendimiento de 52 000 transacciones por segundo! Sin embargo, este enfoque supone dos problemas:
- La seguridad de una cadena de bloques con prueba de participación se mide por el costo de adquirir el 33 % de los tokens participantes y de aprobar transacciones inválidas. Si en lugar de un suministro de tokens único hay 13 redes, el costo de adquirir el 33 % de una red dada se reduce sustancialmente. Eso es mucho menos seguro y perjudica significativamente la propuesta de valor de una cadena de bloques, donde la seguridad es una función del valor de la red.
- El tiempo de compleción para las transferencias entre redes aumenta al menos 4 veces en comparación con las transferencias internas a una misma red. Las redes deben comunicarse entre ellas para sincronizar sus relojes y asegurarse de que si Alice le envía tokens a Bob, él recibe efectivamente el valor en su red antes de que los tokens de ella se quemen en la red de ella.
Mientras que Cosmos prevé un mundo con muchas redes soberanas capaces de gestionar su propia seguridad, Ethereum 2.0, Polkadot, Algorand, Dfinity y Near Protocol son sistemas de construcción que buscan solucionar al menos el asunto de la seguridad compartida (#1 más arriba). Hay diferencias matizadas entre los enfoques de cada equipo, pero la arquitectura básica implica una cadena de baliza única que proporciona un reloj para el resto de la red y al mismo tiempo distribuye a los validadores de forma segura entre los diferentes fragmentos, para que todos compartan una misma red de seguridad. Al igual que con Cosmos, aumentar el rendimiento es fácil: ¡solo hay que añadir más fragmentos!
Imagen: La cadena única de Ethereum 2.0 y el estado fragmentado.
Desafortunadamente, el largo tiempo de compleción para el asunto de las transferencias entre redes (#2 arriba) sigue siendo un problema. Aunque la cadena de baliza ofrece un reloj global, cada fragmento solo sincroniza su reloj local con la cadena de baliza de manera periódica. Para que Alice le envíe tokens desde el fragmento A a Bob en el fragmento B, los validadores del fragmento A deben demostrar que quemaron los tokens de Alice antes de que los validadores del fragmento B acuñen una cantidad equivalente de tokens para Bob. Para el diseño actual de Ethereum 2.0, este proceso tardará 6 minutos, 60 veces más tiempo que el tiempo de bloque entre fragmentos.
Aunque la fragmentación puede ayudar, las limitaciones de escalamiento fundamentales todavía se basan en el hecho de que las actualizaciones de tiempo y estado en cada fragmento están acopladas. Cada fragmento sigue supeditado a las mismas limitaciones que enfrenta Tendermint en cuanto a los tamaños y tiempos de bloque.
La fragmentación es análoga a ciertos elementos del TDMA; el estado se divide en fragmentos separados con sus propios relojes de manera comparable a la forma en que las torres celulares dividen el ancho de banda en radiofrecuencias y franjas horarias separadas. Los beneficios de eso son claros, pero no se aprovechan plenamente, tal y como lo evidencia la latencia entre fragmentos.
Pero ¿qué pasa si es posible desacoplar completamente las actualizaciones de tiempo y estado en una configuración sin permisos?
Separación de tiempo y estado
Hasta ahora hemos analizado cómo Satoshi creó la estructura de datos de la cadena de tiempo para ofrecer un reloj sin confianza para la red de Bitcoin; cómo Kwon y Buchman aplicaron el BPoS a Paxos para reducir de forma segura el número de validadores y acelerar el reloj de la red Tendermint; y cómo la fragmentación de la red en muchas piezas con relojes independientes puede aumentar considerablemente el rendimiento (siempre y cuando las transacciones entre fragmentos se minimicen). Sin embargo, mediante cada una de estas progresiones, observamos que las actualizaciones de estado y tiempo permanecían acopladas, que las actualizaciones de estado solo se producían con cada avance del reloj y que eso le crea límites fundamentales al rendimiento y al tiempo para la compleción para las redes de computación resistentes a la censura y sin permisos.
Separar tiempo y estado requiere un reloj disponible a nivel mundial que sea rápido, preciso y con minimización de la confianza. Con un reloj como ese, las actualizaciones de estado pueden ocurrir de forma continua y asincrónica como ocurren en Spanner. Mientras todo el mundo esté de acuerdo en un reloj global y las transacciones tengan una marca de hora, las transacciones pueden fluir continuamente por la red.
Solana ha construido un reloj con minimización de la confianza para su plataforma de contratos inteligentes separando la cadena de tiemo basada en hash del consenso sobre las actualizaciones de estado. En lugar de encadenar hashes en todos los bloques, los validadores de la red de Solana hacen el resumen criptográfico de los hashes ellos mismos de forma continua, dentro de cada bloque. Ese mecanismo, llamado Prueba de historia (PoH), produce una cadena de tiempo detallada con minimización de la confianza disponible a nivel mundial con el que todos los nodos de la red pueden sincronizarse.
No está dentro del alcance de este ensayo sumergirnos en la mecánica de las pruebas de historia (PoH). Para conocer más información sobre cómo funciona la prueba de historia, consulte la documentación sobre PoH de Solana.
Imagen: Cómo la prueba de historia inserta una marca de hora estandarizada en la cadena de bloques.
La presencia de esta cadena de tiempo independiente le permite al líder que propague las transacciones con marca de hora al comité tan pronto se reciben. La marca de hora proporciona el orden canónico en lugar de una orden arbitraria determinada por el productor de bloques. Los intentos de doble gasto son ahora muy fáciles de resolver, porque toda la red puede ponerse de acuerdo sobre qué transacción se produjo primero.
Eso lo cambia todo.
En lugar de forzar a los validadores a que lleguen a un consenso cada 6 a 600 segundos para verificar el paso del tiempo, los validadores en Solana pueden transmitir actualizaciones de estado a sus pares en tiempo real y de manera continua.
En lugar de tener que esperar la confirmación de cada validador como en todas las demás cadenas de bloques, Solana puede usar un nuevo mecanismo de distribución de paquetes bifurcada llamado Turbine (inspirado en BitTorrent) para hacer que la complejidad de la comunicación sea O(log(n)) en vez de O(n^2). Eso le permite a Solana procesar más de 50 000 transacciones por segundo en un solo estado global con rápida compleción, sin necesidad de fragmentación.
Eso significa que, en el orden de 100-1000, el tamaño del conjunto de validadores es comparable a Tendermint, pero que se permiten las bifurcaciones de la cadena. Se requiere una política de gestión de bifurcaciones agresiva para garantizar que el sistema converja rápidamente en una sola cadena cada vez que surja una bifurcación de cadena. Es el precio necesario a pagar por la progresión asincrónica y la disponibilidad constante.
Continuando con la analogía de la comunicación inalámbrica, podemos decir que la prueba de historia es a las cadenas de bloques lo que el TDMA es a las redes celulares. Imagina a los 1000 validadores de Solana como torres de radio que usan sus relojes sincronizados para subdividir su ancho de banda en franjas horarias individuales. Ellos reciben nuevas transacciones constantemente - cada una con un hash de prueba de historia (PoH) firmado adjunto por el remitente - y luego las envían a sus vecinos, quienes pueden ordenarlas inmediatamente usando esos hashes de PoH. A medida que los líderes rotan en función del reloj global, cada líder elige un conjunto de transacciones ordenadas para ejecutar y luego le chismea esa “entrada” a la red. Los validadores devuelven sus votos en cada “entrada” y finalizan las transacciones cuando ven que las dos terceras partes de los validadores han votado junto con ellos.
La red en su conjunto procesa constantemente transacciones en el mismo orden, manejando volúmenes increíblemente altos, pero cada validador funciona de forma independiente. Ese es un cambio sutil pero profundo en relación con otras cadenas. En Solana, los validadores nunca dejan de funcionar. Siempre avanzan de forma independiente, sin importar las condiciones de la red ni del consenso.
Hay otros asuntos tangenciales (por ejemplo, el crecimiento rápido de la cadena, un nuevo modelo de programación, la imparcialidad de la cadena de tiempo, el paralelismo) que este nuevo diseño saca a la luz pero que están por fuera del alcance de este ensayo, aunque sí se tratan en la documentación de Solana. Hoy las redes de prueba de Solana procesan más de 50 000 transacciones por segundo con un tiempo de compleción promedio de 1,5 segundos en redes de 200 validadores en los 5 continentes. Eso es comparable con Spanner, excepto que está significativamente descentralizado.
Este nivel de desempeño en una computadora mundial con minimización de la confianza y sin permisos solo es posible debido a la separación de tiempo y estado que hace Solana. El reloj disponible a nivel mundial de la red de Solana le permite a cada nodo actualizar su estado sin tener que comunicarse con ningún otro nodo, tal y como hace Spanner.
Creación de un nuevo marco de escalabilidad
Aunque la comunidad de las criptomonedas ha escrito hasta la saciedad sobre los modelos de escalabilidad y consenso, nadie ha explorado específicamente el problema del reloj distribuido. Tras los varios años de investigación en Prueba de participación que culminaron en Tendermint + BPoS como el mejor resultado en su clase y numerosas propuestas de fragmentación que en esencia convergen alrededor de la idea de la cadena de baliza + una arquitectura de fragmentación de estados, una cadena de tiempo detallada que permita la progresión asincrónica de estados proporcionará el mejor desempeño para los sistemas no fragmentados que prefieren la disponibilidad a la consistencia.
Ofrecer un reloj disponible a nivel mundial le permite al equipo de Solana aprovechar más de 40 años de investigación en sistemas distribuidos que, de lo contrario, no serían aplicables. Conceptos como el Control de Concurrencia Optimista se inventaron en 1981 y se han utilizado en proyectos de computación a gran escala durante años, pero no pueden aplicarse cuando tiempo y estado deben funcionar juntos. El procesamiento paralelo con GPU ha existido desde 1995, aunque se limitó en gran medida a las tarjetas gráficas hasta que Nvidia lanzó el entorno de desarrollo CUDA en 2007, pero no pueden ser usados plenamente por sistemas basados en cadenas de bloques que bloquean de manera pesimista todos los estados, menos las cuentas que estén siendo tocadas por alguna transacción en el momento.
Entender el paso del tiempo es fundamental para el desempeño de los sistemas distribuidos, bien sea que requieran permisos o no. El tiempo lo es todo y con una nueva forma de codificar el paso del tiempo en forma de Prueba de Historia, los sistemas que no requieren permisos pueden alcanzar el mismo nivel de desempeño que los proveedores de computación en nube comprobados y centralizados.
Gracias a Anatoly Yakovenko y a Zaki Manian por hacer comentarios sobre este ensayo.
时间与状态之分离
文 Ryan Gentry 译 June Chan
未来一两年间将推出许多 智能合约平台（如以太坊2.0、Polkadot、Dfinity、Near Protocol、 Algorand、Kadena、Spacemesh和Solana）。 每个团队都在追求独特的扩展策略。
然而，大多数这些方法都没有解决拜占庭环境中分布式计算系统的一个基本问题：时钟问题。
Rendimiento [transacciones por segundo] = Tamaño de bloque [transacciones por bloque] / Tiempo del bloque [segundos por bloque]
感谢 Anatoly Yakovenko和Zaki Manian对本文的反馈。
Disclosure: Unless otherwise indicated, the views expressed in this post are solely those of the author(s) in their individual capacity and are not the views of Multicoin Capital Management, LLC or its affiliates (together with its affiliates, “Multicoin”). Certain information contained herein may have been obtained from third-party sources, including from portfolio companies of funds managed by Multicoin. Multicoin believes that the information provided is reliable and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This post may contain links to third-party websites (“External Websites”). The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites.These links are provided solely as a convenience to you and not as an endorsement by us of the content on such External Websites. The content of such External Websites is developed and provided by others and Multicoin takes no responsibility for any content therein. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in this blog are subject to change without notice and may differ or be contrary to opinions expressed by others.
The content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. You should consult your own advisors for those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by Multicoin, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by venture funds managed by Multicoin is available here: https://multicoin.capital/portfolio/. Excluded from this list are investments that have not yet been announced due to coordination with the development team(s) or issuer(s) on the timing and nature of public disclosure. Separately, for strategic reasons, Multicoin Capital’s hedge fund does not disclose positions in publicly traded digital assets.
This blog does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by Multicoin. An offer or solicitation of an investment in any Multicoin investment vehicle will only be made pursuant to an offering memorandum, limited partnership agreement and subscription documents, and only the information in such documents should be relied upon when making a decision to invest.
Past performance does not guarantee future results. There can be no guarantee that any Multicoin investment vehicle’s investment objectives will be achieved, and the investment results may vary substantially from year to year or even from month to month. As a result, an investor could lose all or a substantial amount of its investment. Investments or products referenced in this blog may not be suitable for you or any other party.
Multicoin has established, maintains and enforces written policies and procedures reasonably designed to identify and effectively manage conflicts of interest related to its investment activities. For more important disclosures, please see the Disclosures and Terms of Use available at https://multicoin.capital/disclosures and https://multicoin.capital/terms.