A día de hoy, aproximadamente 3800 millones de personas cuentan con una cuenta bancaria en las cuales operan diariamente realizando distintos tipos de transacciones económicas. Es por ello que es esencial que estas operaciones ocurran de manera casi inmediata, sobre todo teniendo en cuenta los tiempos que corren donde 5 segundos pueden parecer una eternidad. Por el contrario, las blockchains Layer 1 tales como Bitcoin o Ethereum, que quieren imponerse sobre los sistemas económicos centralizados, tienen problemas para acercarse a los valores que los bancos ofrecen. Para poner un ejemplo, Visa procesa alrededor 24 mil transacciones por segundo, mientras que en Ethereum el número es alrededor de 30. Como podemos observar, esto parecería ser un gran problema.
En enero de 2018, Eli Ben-Sasson, Uri Kolodny, Michael Riabzev y Alessandro Chiesa fundan Starkware en Israel, Netanya con el fin de solucionar el problema de escalabilidad inherente a la blockchain de Ethereum en conjunto con todas aquellas que son compatibles a la EVM, sin perder en el camino la seguridad que brinda por default. Esto lo hacen utilizando la tecnología inventada por Ben-Sasson y Michael Riabzev: las zk-STARKs.
El nombre de estas pruebas proviene de las propiedades de la misma: zero knowledge - Scalable Transparent ARgument of Knowledge.
Estas son un tipo de pruebas criptográficas altamente seguras que usan los principios de las Pruebas de Conocimiento Cero (ZKP) para crear datos cifrados que pueden ser fácilmente verificados sin revelar información sensible sobre dichos datos, y lo mejor de todo, es que cuentan con resistencia a la computación cuántica garantizando así su seguridad en un futuro no tan lejano.
Las ZK proofs son una forma de dar validez a una información sin la necesidad de revelar dicha información. Estas surgieron teóricamente a partir de un paper publicado en 1985. Con el tiempo han ido evolucionando hasta el punto de que hoy en día ya son utilizadas por varias aplicaciones del mundo real. Un ejemplo muy simple es la utilización que les da a estas pruebas el banco holandes ING, el cual las utiliza para determinar si un cliente puede o no aplicar a un préstamo sin la necesidad de que el banco sepa cuánto dinero gana el cliente en cuestión.
Las interactive zk proof siguen 3 pasos:
(Witness) El prover tiene un set de preguntas que solo pueden ser respondidas si este realmente tiene la información que dice tener. En este paso, el prover envía al verifier la respuesta a una de las preguntas elegidas de forma aleatoria.
(Challenge) Ahora el verifier elige, al azar, otra de las preguntas del set y se la envía al prover para que este la responda.
(Response) El prover recibe el challenge y envía la respuesta al verifier.
Estos pasos permiten al verifier determinar si el prover está respondiendo a las preguntas de manera aleatoria o si realmente tiene la información que dice tener. Como el set de preguntas es muy grande y la probabilidad de acertar dos respuestas de manera aleatoria es muy baja, el verifier puede asumir que la información es verdadera.
El problema con este tipo de pruebas es que el resultado de la prueba es individual al verifier node por lo que no resuelve el problema de la escalabilidad. Es por ello que las STARKs utilizan las non-interactive zk proofs.
Estas reducen el proceso de comunicación mediante el envío de una clave compartida entre el prover y el verifier. De esta manera, el prover puede demostrar que conoce la información sin tener que revelarla. Además, la gran ventaja que tienen estas es que el resultado de la prueba es válida para todo nodo que cuente con acceso a la clave compartida y el algoritmo de verificación.
De esta forma, podemos proveer una forma de verificar la información sin la necesidad de que todos los nodos ejecuten la prueba y sin tener que revelar la información verificada.
El problema de las zk-proofs es que para poder realizar estas pruebas, antes de comenzar el proceso de verificación hay que inicializar un entorno confiable entre las partes involucradas, que en definitiva, pone en riesgo de comprometer la privacidad de todo el sistema si no se hace correctamente.
Lo innovador de la tecnología inventada por los fundadores de StarkWare es que al utilizar las STARKS, esto no es necesario. Gracias a esto, es posible aumentar en gran medida la cantidad de transacciones que pueden realizarse por segundo, aumentando así la escalabilidad.

Starkware ofrece dos productos principales que utilizan este concepto. Extraen la ejecución de las zk-proofs a una segunda capa L2, y prueban que la transacción fue válida a la blockchain que en este caso es Ethereum.
El primero de estos es StarkEx, el cual funciona como un motor de escalabilidad que provee una API la cual brinda un conjunto de servicios para distintos tipos de aplicaciones. La idea es que estas aplicaciones lo utilicen como backend. Las funcionalidades en sí interactúan con la blockchain de Ethereum mediante código predefinido hecho a medida para cada aplicación (implementado en Cairo).
Un ejemplo de aplicación que utiliza StarkEx es Immutable X. Una solución que ofrece escalabilidad al mercado de los NFTs. Es principalmente usado por juegos de web3, donde es necesario mintear gran cantidad de NFTs, sin pagar los costos en gas prohibitivos de la red de Ethereum.
En cuanto a la seguridad de este producto, PeckShield (una de las compañías de mayor categoría en el ámbito de la seguridad a nivel blockchain) se encargó de auditar los smart contracts antes de lanzar el acuerdo con dYdx. En el reporte se encontraron únicamente 4 vulnerabilidades de las cuales ninguna fue de carácter crítico.
La idea de Starkware a futuro, es que las aplicaciones que corren sobre StarkEx puedan ser porteadas a Starknet.
El segundo es Starknet, sobre el cual vamos a estar haciendo un poco más de foco. Starknet es una ZK-rollup. La idea de este producto es que se pueda correr cualquier aplicación, en lugar de únicamente ofrecer un conjunto servicios predefinidos. Esto lo logra mediante una Layer 2 sobre la cual corren dichas aplicaciones.
Dado que Starknet no es EVM compatible, esta tiene su propia Virtual Machine: Cairo VM. Esta define su propio lenguaje, Cairo, el cual es Turing completo, y tiene como principal objetivo posibilitar y facilitar la generación de pruebas STARKs. Con Cairo se implementan los smart contracts, los cuales afectan el estado de la L2 donde corre Starknet. Gracias a esto, cualquiera puede escribir su propio smart contract en Cairo y deployar sobre la red de Starknet.

El flujo es el siguiente:
Un cliente envía una transacción al Sequencer de Starknet
El Sequencer elige cuáles transacciones van a ser incluidas en el bloque actual
Starknet ejecuta las transacciones elegidas
Luego el prover genera el STARK que verifica la validez de cada transacción.
El STARK es enviado a la blockchain de Ethereum, donde el verifier verifica que la prueba criptográfica es válida
Se actualiza el estado de la red principal de Starknet en la mainnet
De esta forma, se pueden ejecutar muchas más transacciones, al no tener que ejecutar cada una en N nodos. Lo que realmente se ejecuta en el blockchain, es únicamente una verificación de la prueba criptográfica, lo cual es mucho más liviano en términos de costos de ejecución.
Haciendo esto, no se pierde la seguridad de Ethereum, ya que todas las transacciones son verificadas en la blockchain, y al mismo tiempo se puede brindar muchas más transacciones por segundo, ya que, la generación de las pruebas criptográficas escala cuasi linealmente.
Otra de las cosas importantes con las que cumple Starknet es la posibilidad de que los smart contracts de la red interactúen con los smart contracts de la L1 sobre la cual está implementada, ya que lo que se busca es evitar que sea un sistema aislado. Puede ocurrir de 2 formas, de Starknet a Ethereum o viceversa. A la hora de diseñar los smart contracts de la L2, es recomendado que estos tengan su contraparte en L1 en conjunto con el protocolo de mensajería que utilizan para comunicarse. El caso más común es la mensajería de Starknet hacia Ethereum, por ejemplo en una transacción de retiro de fondos.
Dónde Starkware sí tiene una desventaja es en la descentralización. De momento hay un único prover, el cual es manejado por Starknet, ya que se requiere una capacidad computacional muy grande para generar los STARKs. Además, el algoritmo del mismo no es de código abierto, por lo que no cualquiera podría correr su propio Prover
Sin embargo, Starknet no puede generar pruebas ni transacciones falsas, por lo cual esto no es un problema de seguridad.
Hoy en día, Starkware no es la única solución que hay en el mercado para tratar de solventar el problema de la escalabilidad en las blockchains compatibles con la EVM.
Una de las alternativas es Optimism, la primera L2 de Ethereum compatible con la EVM que implementa una Optimistic Rollup. Al igual que Starknet y Starkex, esta se ejecuta junto a Ethereum por lo que hereda la seguridad de la blockchain por default. Una de las particularidades de Optimism es que por default, se asume que todas las transacciones son válidas y utiliza Fraud Proof System para verificar que estas transacciones realmente lo sean.
En este sistema, cualquier nodo de la red puede desconfiar de la validez de una transacción. En base a ello, la rollup procederá a calcular la transacción en Ethereum para determinar si el verifier node estaba en lo correcto o no. Si la transacción era invalida, el sequencer node (aquel que propone la transacción) será penalizado y el verifier node obtendrá un reward. En cambio, de ser válida la transacción, los sequencer nodes cobrarán una comisión por el servicio prestado.

Una de las grandes ventajas que ofrece la solución brindada por Starkware en comparación a la de Optimisms es que las STARKS son muy superiores en velocidad a las Fraud Proof lo cual permite un mayor un throughput de operaciones por segundo.
Otra de las alternativas populares es Arbitrum, que tambien se clasifica como una Optimistic Rollup. Esta se caracteriza por realizar multiples rondas de Fraud Proofs que se ejecutan en L2. Esto hace que sean incluso mas baratas que Optimism. Otra de las cosas a destacar es que tienen su propia Virtual Machine: la Arbitrum Virtual Machine (AVM).
Por otro lado, a nivel tecnológico, las STARKs también tienen su competencia directa: las SNARKs y las BulletProofs. Las SNARKS son un tipo de zk-proofs pero difieren con las STARKs en algunas cosas. Por ejemplo, este tipo de pruebas si o si requieren un setup confiable mientras que las STARKs no. Además, no están pensadas para resistir ataques cuánticos, ya que usa criptografía asimétrica para el uso de claves.

Las BulletProofs, al igual que las STARKs, no requieren de un setup confiable. La ventaja que tienen es que son más cortas pero, en contrapartida, llevan más tiempo en generar y ser verificadas.

A día de hoy, los HeadQuarters de Starkware se encuentran ubicados en Netanya, Israel donde más de 100 empleados trabajan en el proyecto (en Linkedin actualmente cuentan con 102 asociados). En el apartado financiero, son considerados un proyecto “unicornio” a nivel mundial ya que el valor de la compañía ya superó los mil millones de dólares. Específicamente, en mayo de 2022, el valor de la compañía llegó a los $8B USD.
En cuanto al equity de la compañía, el valor fijo total es de $463M USD. Este está compuesto únicamente por las plataformas de StarkEx ya que StarkNet se encuentra en alpha en mainnet. A su vez, en dichas plataformas acumularon 247 millones de Tx por las cuales intervinieron $726B USD.
Starkware se ocupa de publicar un blogpost con una frecuencia relativamente corta. Suelen subir una nueva actualización su página una o dos veces al mes y suelen publicar varios tweets acerca de la actualidad de los proyectos en los que trabajan. Sobre todo Starknet.
En el corto plazo, está en los planes de Starknet lanzar su propio token, para dar recompensas a los operadores (aquellos que dan poder computacional a la red) y desarrolladores (tanto de smart contracts como del desarrollo interno de la red).
Esto es solo uno de los primeros pasos en los planes de descentralización que tiene Starknet. Para esto necesitan tener un token nativo, que sea usado tanto para gobernanza como para pago de los fees por transacción de la red. Además del Token, se inicia una fundación llamada la Starknet Foundation, que va a ser la encargada de la gobernanza de la red de Starknet, tomando decisiones sobre su dirección y desarrollo a futuro. Las decisiones serán tomadas en base a un esquema básico de gobernanza, donde se requerirá una mínima cantidad de tokens para generar propuestas de mejoras para la red, y para votar sobre las mismas.
A partir de la Fundación y el Token, la idea es que Starknet pase a ser un bien público como Ethereum, que pueda continuar funcionando incluso si Starkware dejase de existir. En base a esto se debe lograr una red resistente a la censura y transparente.
A modo de cierre les dejamos más links para que puedan profundizar sobre estos temas:

