Limitaciones de la aproximación al sharding de Zilliqa

29 de agosto de 2018|ALEXANDER SKIDANOV

Zilliqa ha publicado hoy una entrada de blog sobre su diseño de sharding.

Es evidente que si no dispones de sharding desde el primer día, tu blockchain no tendrá opciones de escalar a medida que sea adoptada. Construir sharding a posteriori resulta extremadamente difícil. Sirva como ejemplo el hecho de que Ethereum tenga uno de los equipos de ingenieros más potentes del ámbito blockchain y, sin embargo, su lanzamiento de sharding haya vuelto a ser pospuesto. En su caso, integrar sharding en el sistema es algo similar a cambiar el motor de un coche mientras éste se encuentra en marcha.

Zilliqa es uno de los pocos proyectos que ha prometido sharding, y por ese motivo lo hemos seguido de cerca desde los inicios.

Yo fui el ingeniero #1 en una compañía de bases de datos llamada MemSQL. MemSQL construye una plataforma de análisis distribuido que dispone de grandes clusters desplegados en Goldman Sachs, Uber, Comcast, Akamai y muchas otras compañías. Mientras estuve en MemSQL, fui responsable de su implementación de sharding. Posteriormente, cofundé Near Protocol, donde también trabajan dos de los primeros ingenieros de MemSQL que fueron responsables de las transacciones cross-shard y complex distributed joins, así como cuatro ingenieros que trabajaron en Google.

En el pasado, hemos construido ya sharding que propulsaba grandes clusters en producción y procesaba millones de transacciones por segundo por cada nodo agregador. Como resultado de nuestra experiencia, sabemos bien cómo implementar sharding en sistemas complejos y qué problemas prácticos puede presentar.

Volviendo al post de Zilliqa post, la esencia de su mensaje puede ser resumida en varios puntos:

• Ejecutar todas las transacciones de shard único (single-shard transactions) en paralelo;
• No ejecutar las transacciones que afectan al mismo smart contract en paralelo;
• No ejecutar ninguna transacción que afecte a más de un shard, en paralelo con cualquier otra transacción.

Aparte de esto, y aunque no se afirme de manera explícita en la entrada del blog, se desprende que Zilliqa no aplica sharding al estado (este FAQ de Ethereum ofrece una explicación de las diferencias entre sharded state y sharded processing).

EJECUCIÓN EXCLUSIVA DE SINGLE-SHARD TRANSACTIONS (TRANSACCIONES DE SHARD ÚNICO) EN PARALELO

Ejecutar en paralelo solamente las transacciones en las que el iniciador (transaction initiator) y el smart contract se encuentran en el mismo shard podría no ser un gran problema. En Fleta, los pagos han sido diseñados partiendo de la idea que las shards pueden ser tratadas de forma intercambiable. Es algo que no acaba de funcionar del todo para Zilliqa, dado que en Fleta la shard es dictada por el emisor, mientras que en Zilliqa es dictada por la shard del contrato; aunque sugiere que una idea similar podría ser aplicable.

AUSENCIA DE STATE SHARDING (SHARDING DE ESTADO)

No someter el estado a sharding nos facilita la vida. Para verlo más claro, con sharded state incluso el primer ejemplo de la entrada del blog de Zilliqa queda obsoleto: asignar el pago al shard del emisor no resultaría suficiente, dado que el shard del emisor no tendría la capacidad de actualizar el estado del receptor. Como resultado, una tarea tan simple como procesar pagos se vuelve muy compleja una vez el estado ha sido sometido a sharding. Sin embargo, vale la pena señalar que incluso en ausencia de sharding de estado, la asignación de pagos al shard del emisor sólo funciona si las cuentas están representadas como UTXO. Si las cuentas almacenan la cantidad acumulada, entonces dos shards que procesen transacciones con el mismo receptor aplicarán en la cuenta del receptor actualizaciones conflictivas.

Ahora bien, no someter a sharding el estado, aunque simplifica el diseño de sistema, impone un límite enorme a la escalabilidad del sistema. La única razón por la que los nodos de Ethereum aún pueden almacenar todo el estado es que Ethereum sólo procesa 14 transacciones por segundo. En el momento en que un sistema pasa a procesar miles de transacciones por segundo, el estado se dispara, debido a que las transacciones dejan un rastro en el mismo. Introducir sharding de estado a posteriori resulta tan complicado como introducir sharded processing (sharding de procesamiento) en protocolos blockchain modernos “no shardeados”.

NO EJECUTAR TRANSACCIONES QUE AFECTAN AL MISMO SMART CONTRACT EN PARALELO

De manera análoga, no someter a sharding el procesamiento de los smart contracts, aunque simplifica la implementación, limita la escalabilidad de un protocolo. En última instancia, en cualquier ecosistema, unas pocas aplicaciones acaban dominando el uso; y en cuanto Zilliqa escale hasta alcanzar miles de shards, las cinco dApps principales tendrán que residir en cinco de éstas, y se verán limitadas tanto por la potencia de procesamiento de las mismas como por su almacenamiento (una vez se haya introducido el sharding de estado).

Dadas las limitaciones descritas arriba, junto con el no procesamiento de contratos que por diseño afectan a múltiples shards en paralelo, Zilliqa simplemente supondrá un cambio de tipo incremental en el panorama de las blockchains escalables. Podría superar en rendimiento a EOS, Thunder y Algorand (o al menos ofrecer una mejor decentralización que los dos primeros), pero su futuro no está garantizado, y dichas limitaciones impedirán que escale junto con la demanda de la plataforma de aplicaciones descentralizadas.

El área de investigación que se ocupa de la ejecución de transacciones distribuidas tiene una larga historia, y no debe ser ignorada en el desarrollo de protocolos blockchain de tipo sharded.

Por poner un ejemplo, implementaciones de Map-Reduce, o, en general, motores que conllevan procesamiento paralelo, shuffles y agregaciones, han sido empleados para ejecución paralela de transacciones complejas desde hace más de una década.

¿Por qué no vemos entonces una emergencia de protocolos blockchain de tipo sharded impulsados por técnicas acreditadas por la industria? La razón principal es que crear sistemas distribuidos ante la presencia de fallos es una tarea de ingeniería extremadamente compleja. El número de database systems distribuidos que han sido testeados en producción y que no provienen de gigantes de la ingeniería como Amazon, Microsoft, Google o Facebook -los cuales disponen de acceso al mejor talento en ingeniería de sistemas distribuidos- es muy pequeño.

En este sentido, Near Protocol, con su excepcional equipo de ingenieros de sistemas distribuidos, está posicionado de forma única para construir un motor de aplicaciones descentralizadas sujeto a sharding.

En este momento, no tenemos acabado todavía nuestro artículo técnico sobre sharding — pero lo publicaremos pronto. La manera en que desarrollamos nuestro enfoque es de naturaleza más práctica, lo que implica construir primero un prototipo para poner a prueba todas nuestras hipótesis. En un campo tan complicado como el de los sistemas distribuidos, escribir un whitepaper antes de tener una implementación en funcionamiento es, a menudo, una decisión precipitada -aunque parece ser un enfoque adoptado de forma amplia por los proyectos de blockchain.

En el nivel más alto, las transacciones en Near se dividen en un conjunto de “map” steps paralelos, intercalados por “shuffle” steps, y el estado y la ejecución de cada smart contract está sometida a sharding. Esto permite la ejecución en paralelo de programas arbitrariamente complejos. Además, Near no introduce su propio lenguaje de programación, sino que se apoya en todo el ecosistema de transpiladores a WebAssembly, así como en el acceso al estado mediante queries de SQL.

¡Mantente conectado para nuestro artículo técnico de sharding!

Para seguir nuestros progresos puedes usar:

• Twitter — https://twitter.com/nearprotocol,
• Medium — https://medium.com/nearprotocol