El Roadmap de Ethereum para dummies
Entiende por fin el camino de Ethereum hacia su forma definitiva
por Antonio Fernández de beToken Research
Recientemente leí un artículo de Delphi Digital, The Hitchhiker’s Guide to Ethereum, en el que Jon Charbonneau sumariza y explica con pelos y detalles todas las diferentes actualizaciones y mejoras que llevarán a Ethereum poco a poco hacia su forma definitiva, después del ansiado Merge, su transición de PoW a PoS. Todo bien documentado, compacto y “listo para asimilar”. Hasta el mismo Vitalik Buterin, padre de Ethereum, disfrutó de lo acertadas que fueron las palabras de Jon. Ilusionado, me lancé a devorarlas. Por desgracia, entender todo aquello me llevó más horas de las que querría admitir, y mi cabeza volvió a recordar los tiempos en los que estudiaba física y me acurrucaba en un rincón de mi cuarto al enfrentarme a mi primer problema de Teoría Cuántica de Campos.
Pero he logrado salir de allí, y lo que he aprendido es un hermoso sistema interconectado que, aunque lentamente (espero seguir vivo cuando terminen las actualizaciones), tal vez lleve a Ethereum a la descentralización, seguridad y escalabilidad definitiva que sus desarrolladores desean, de forma elegante. Así que me comprometo, en este artículo, a desgranar todas estas mejoras, y ofrecértelas en bandeja, para que puedas digerirlas y que hagan “click” en tu cabeza, como han hecho en la mía, sin sufrir tanto como yo, y puedas juzgar con opinión fundamentada si realmente merece la pena apostar a largo plazo en un Ethereum que busca alcanzar sus objetivos sin tomar atajos, con paso firme, pero meditado con tiempo y a fuego lento.
Bienvenidos, Tokeners, al Roadmap de Ethereum para dummies.
El camino hacia un Ethereum post-Merge perfecto
Si has estado atento últimamente en el criptoverso, o si lees nuestra newsletter de forma habitual, seguramente estés enterado de que el ansiado Merge de Ethereum, su transición de mecanismo de consenso PoW a PoS, se encuentra cada vez más “cerca” (su retraso es ya todo un meme, pero nosotros tenemos esperanzas en que lo veamos completado este mismo año).
Sin embargo, si leíste mi artículo sobre el Merge (si no es así, te lo recomiendo, pues te servirá para entender todo un poquito mejor), sabrás de sobra que esta actualización no solucionará los problemas actuales de Ethereum, tales como sus costes de gas prohibitivos, su procesamiento pobre de 15 transacciones por segundo, o sus requerimientos computacionales cada vez mayores para participar en su consenso.
Lo que sí que hará el Merge es dar los primeros pasos hacia una inmensa y compleja serie de actualizaciones, interconectadas entre ellas, con nombres rimbombantes y con tecnicismos en tales cantidades que hacen sonrojar incluso a expertos en la materia.
Pues bien, antes de profundizar en cuál será la naturaleza de estas mejoras, es necesario definir hacia dónde llevarán a Ethereum.
Como ya expliqué en el artículo sobre el Merge, una blockchain Layer 1 definitiva busca ser tres cosas a la vez: descentralizada, segura y escalable. Esto se conoce como el Trilema de las Blockchains, pues, para conseguir dos de las tres características, es necesario renunciar a la tercera. El Ethereum PoW que conocemos hasta el día de hoy es altamente descentralizado y seguro. Sin embargo, no es escalable, como demuestran todos sus problemas actuales.
Por tanto, las actualizaciones buscan lo “imposible”: mejorar la escalabilidad de Ethereum, sin comprometer su descentralización y seguridad. Eso sí, una vez todo haya sido completado, la blockchain del Ether que conocemos habrá cambiado sustancialmente de cómo la conocemos ahora…
Un Ethereum cubierto por Rollups
Recientemente, los desarrolladores de Ethereum han tenido una epifanía: ¿por qué deberíamos centrarnos en mejorar la velocidad de computación de transacciones, y su ejecución en Ethereum, cuando ya lo están haciendo los Rollups por nosotros?
Arbitrum, Optimism, Polygon (no es rollup, pero funciona de forma similar), Starknet,... Los Rollups exitosos construidos sobre Ethereum ya no se pueden contar sólo con los dedos de las manos, y todos ellos prometen un enorme procesado de transacciones, y costes de gas irrisorios…. Oh, espera, ¿no sabes lo qué es un Rollup?
Explicados de forma sencilla, puedes considerarlos como “blockchains” independientes que publican periódicamente sus datos de transacciones comprimidos (enrollados como una alfombra, de ahí el nombre de Rollups) a Ethereum, para que queden allí grabados y, por tanto, hereden su seguridad, y, a cambio, le quiten carga computacional.
El caso es que los datos que los Rollups suben a Ethereum son de vital importancia para su funcionamiento, pues son utilizados para verificar que las transacciones que se han realizado en ellos son correctas. En el caso de los Optimistic Rollups, se puede demostrar que se han realizado transacciones incorrectas o maliciosas mediante el análisis de estos datos, y proporcionando a partir de ello una Fraud Proof. Mientras que los zk-Rollups suben junto con los datos una prueba de su veracidad, para que cualquiera pueda asegurarse de ella.
Hoy en día, la mayoría de proyectos cripto de Ethereum se construyen en sus Layer 2, antes que en la propia blockchain. Es por esto que Ethereum, para escalar, buscará a partir de ahora ser lo más cómoda posible como para sostener a un ecosistema de Rollups, permitiendo que éstos puedan enviar cantidades enormes de datos a la blockchain, sin que esto suponga un problema para su integridad. Nótese que Ethereum inicialmente no fue construida para ir all-in con los Rollups, por lo que hay mucho que optimizar.
Ahora ya podemos adentrarnos con convicción en las actualizaciones del Roadmap en sí. Empecemos con la artillería pesada: Ethereum tendrá 4 grandes cambios, entrelazados entre ellos, que lo llevarán hacia el centro del Trilema Blockchain, y lo harán la Layer 1 de Rollups definitiva: Proposer-Builder Separation, Data Availability Sampling, Weak Statelessness y Danksharding.
Agarraos fuerte, Tokeners.
Proposer-Builder Separation (PBS)
El problema: los nodos lo hacen TODO
La clave para que Ethereum se mantenga descentralizada es que cualquier persona pueda acceder con su modesto laptop (y algo de ETH, por supuesto) a un nodo validador de la blockchain, y pueda comenzar a participar en su mecanismo de consenso.
Actualmente esto no es posible: los nodos tienen dos trabajos: construir el siguiente bloque de la blockchain ejecutando todas sus transacciones, colocándolas en un orden correcto, y actualizando el estado de la blockchain, al mismo tiempo que participan en su consenso.
En el caso de PoW, los nodos compiten entre ellos resolviendo un problema computacional de hallar un hash correcto a partir del bloque anterior, y luego, si lo consiguen, colocan su bloque en la cadena existente con más bloques (no es necesario profundizar más en PoW para este artículo, no te preocupes).
En el caso de PoS, post Merge, la cosa cambia un poco. Si no has leído mi artículo del Merge, te dejo aquí un resumen:
La blockchain se divide en épocas, que tienen 32 slots. En cada slot entra un bloque, que está conectado con el del anterior slot. Se selecciona pseudo-aleatoriamente del pool de validadores para cada slot a un proposer, un validador que construirá un bloque, y lo propondrá en el slot para que un comité de validadores compruebe que es correcto, y firme por el bloque. Si se alcanzan las suficientes firmas (⅔), el bloque se asigna al slot. Este proceso dura 12 segundos. Cuando se completan dos épocas sin problemas, los bloques de éstos se consideran finalizados. Esto implica que la finalidad de las transacciones se realizará en aproximadamente 12,8 minutos.
Construir un bloque es computacionalmente muy exigente, por lo que, aunque no siempre seas el proposer, vas a necesitar mucho poder computacional para cuando te toque serlo.
Solución: necesitamos un builder
La solución podría hacer que a alguno se le levante la ceja: se creará un nuevo rol en la blockchain: los builders. Serán nodos con un enorme poder computacional, controlados por agentes especializados que se encargarán de construir bloques, y entregarlos a los proposers de turno. Éstos seleccionarán el bloque con mayor MEV (Maximal Extractable Value, es decir, el mayor valor extra, aparte de las tarifas de transacción, que se pueda conseguir colocando ciertas transacciones, omitiéndolas, o reorganizándolas en un bloque), y lo entregarán a los comités del respectivo slot para que lo validen y lo añadan potencialmente a la blockchain.
Si aún no se te ha levantado la ceja, tal vez te tiemble la nariz, porque esto huele a centralización. Una persona normal no podría controlar un nodo builder. Sin embargo, es una centralización necesaria, pues de este modo se elimina por completo la necesidad de que los nodos que validen Ethereum tengan que construir bloques, y se centren en simplemente asegurarse que sus transacciones son correctas.
Siempre y cuando 1 solo de todos los builders no sea malicioso, este sistema funcionaría, pues la palabra final sobre qué bloque entra en la blockchain es de los validadores, más descentralizados al no requerir software exigente. Si les llega un bloque incorrecto, pueden rechazarlo hasta que les llegue uno verídico. Y para evitar que los builders censuren transacciones, el proposer puede obligarles a incluir las que él quiera en un bloque, mediante lo que se conoce como censorship-resistant lists.
Y como guinda en el pastel, se puede exigir incluso que el bloque sea mayor, ya que el peso computacional que ello implica se lo llevan los builders, que son más que capaces. Es un sistema simple y elegante.
Data Availability Sampling
Está muy bien eso de que los stakers de ETH puedan validar la red sin preocuparse del MEV, ni de la pesada tarea de ejecutar todas las transacciones de la blockchain y construir un bloque. Sin embargo, aún con eso sigue habiendo un serio problema: para comprobar que un bloque sea válido, los validadores tienen que descargarlo por completo. Si no, podrían saltarse una transacción en la que, por ejemplo, todo tu balance de ETH es transferido a la cuenta de fulanito_99, y eso, supongo, que no te haría ninguna gracia… Con el aumento del tamaño del bloque, y con toda la cantidad ingente de datos que envían los Rollups a la blockchain, esto es sin duda otro serio impedimento para que las personas normales puedan participar en el consenso de Ethereum.
Es aquí donde entra el Data Availability Sampling. De forma resumida: son una serie de actualizaciones cuyo propósito es que los validadores puedan demostrar con casi 100% de certeza que todos los datos del bloque se encuentran disponibles, solo con analizar una pequeña porción de ellos. Como Jack el Destripador diría “vayamos por partes”…
La Disponibilidad de Datos es la clave
La clave para entender todo esto es que los Rollups no necesitan que los validadores de Ethereum comprueben todas las transacciones y datos que suben allí. Les vale con que aseguren que estos datos estén disponibles (de ahí lo de Data Availability) para que cualquiera pueda descargarlos. En el caso de un Optimistic Rollup, por ejemplo, cualquiera así puede demostrar que una transacción es incorrecta emitiendo una Fraud Proof a partir de estos datos. Ahora bien, por desgracia, nos toca estudiar un poco de matemáticas.
¿Cómo funciona el Data Availability Sampling?
Okeey, si no te apetece volver al trauma de las matemáticas te puedes saltar este apartado, y considerar que el Data Availability Sampling funciona gracias a “magia polinómica”, que permite que un validador pueda reconstruir gran parte de un bloque analizando solo una pequeña parte de él.
En cambio, si te interesa saber cómo funciona, vamos allá:
Los builders de Ethereum darán a los validadores una parte del bloque dividido en “paquetes de datos”, relacionados entre ellos. Consideremos ahora que estos paquetes de datos son coordenadas de una gráfica bidimensional (x e y). Supongamos que un validador coge 4 de ellas: (, , y ).
Os presento ahora a un polinomio de grado 3: y(x) = * + * + *x + , construido con las coordenadas anteriores, en función de un valor cualquiera, x.
Se puede evaluar el polinomio en distintos puntos, resolviendo ecuaciones, para hallar esas coordenadas. Por ejemplo, la más sencilla: y(0) = .
Una vez tenemos las evaluaciones, podemos extender los datos a 4 nuevas evaluaciones del mismo polinomio, es decir, unos puntos (, , , ) que satisfagan la ecuación de arriba en otro lugar de la gráfica. Visualmente quedaría así.
Estos puntos son, básicamente, otros datos distintos del bloque, obtenidos a partir de los originales. Esto implica que puedes reconstruir un bloque entero con solo la mitad de sus datos. El builder tendría que esconder más de un 50% del bloque para engañar a los validadores.
El Data Availability Sampling es realizar este proceso numerosas veces, hasta que sea casi 100% seguro que todos los datos del bloque están disponibles. De hecho, con hacerlo 30 veces de forma exitosa, la probabilidad de que no estén todos los datos es de .
Ya para terminar con esta sección, hay mucho más en todo este proceso de Data Availability Sampling del que te he contado: véanse los KZG Commitments, más “magia polinómica” que permite demostrar que los datos que se han extendido son consistentes, y no datos colocados de forma aleatoria para despistar. Esto acaba implicando que realmente es necesario que el 75% del bloque esté disponible para no engañar a los validadores.
Weak Statelessness
Nuestros nodos validadores están ya mucho más relajados, ahora que le han cedido el trabajo de construir bloques a los builders, y han estudiado matemática avanzada para hacerse la vida más fácil a la hora de validar, en vez de ir a lo bruto. Sin embargo, se encuentran con que tienen un grave problema de síndrome de diógenes…
Y es que los nodos actuales almacenan absolutamente TODO. Cada nodo posee todas las transacciones e historia de la blockchain desde su bloque génesis, es decir, terabytes de datos que crecen cada vez a ritmo mayor. Al mismo tiempo almacenan todo el estado de la blockchain, es decir, todas las variables internas de Smart Contracts que se actualizan al enviarles transacciones.
Está claro que hay que hacer algo… Si fuera un validador de Ethereum, me gustaría tener algo de espacio de almacenamiento extra en mi humilde portátil, aunque sea para jugar al buscaminas. La solución está clara… ¡Toca recortar!
No necesitamos TODO el estado
Gracias al Proposer Builder Separation, los validadores ya no necesitarán almacenar todo el estado de la blockchain, pues realmente este es solo necesario para construir los bloques. Así que eso se lo dejamos al builder. En cambio, para validar transacciones, los validadores usarán lo que se conoce como witnesses.
Los witnesses son pruebas que suben los builders junto con el bloque, y que contienen la mínima información necesaria sobre el estado para que los validadores comprueben que las transacciones del bloque son correctas.
Y esto es básicamente conocido como Weak statelessness: los validadores no necesitan todo el estado de la blockchain, sino solo una pequeña parte.
Esta actualización tendría implicaciones maravillosas tales como subir los límites de gas un x3. Por desgracia, no es tan fácil de implementar, y requiere de tecnología de criptografía avanzada, la cual por motivos de sanidad mental no explicaré aquí. En concreto, se requiere de Verkle trees.
Estado con fecha de caducidad
Imagina que un Smart Contract queda obsoleto, y sus usuarios migran a otro diferente y mejor. Todo el estado de ese Smart Contract queda también obsoleto, y aún así está siendo almacenado por todos los nodos de la blockchain, aunque no vaya a ser usado nunca más. Por tanto, en un futuro, se permitirá a los nodos borrar permanentemente el estado que lleve inactivo más de un año. Si por algún casual se desea recuperarlo, habrá que acudir a algún servicio que almacene la historia de la blockchain, y publicar on-chain una prueba de que deseas reactivar el estado. Lo que me lleva al siguiente punto:
Historia con fecha de caducidad
Aunque borres el estado de la blockchain, sigues manteniendo almacenados todos los bloques de la blockchain desde su génesis. Para solucionar esto, volvemos a acercarnos a terreno escabroso: “hay que confiar en una entidad tercera”… La solución será que los nodos borren todos los datos históricos de la blockchain de más de un año de edad. Si queremos acceder a ellos, habrá que obtenerlos de alguna entidad tercera que sí que tenga todo almacenado. Siempre y cuando una de estas entidades sea honesta, podremos recuperar los datos. Un sacrificio necesario para alcanzar la ligereza deseada para una red de nodos descentralizada.
De eterno “calldata” a “blobs” fugaces
Ojito, todavía queda un importante elemento a la hora de aligerar la carga de los nodos. Esto tiene que ver directamente con los datos que suben periódicamente los rollups a Ethereum. Actualmente, lo hacen en forma de calldata. Esta es, básicamente, la forma de almacenamiento en Ethereum más barata actualmente, y no tiene que ver con el estado de la propia blockchain. Aún así, los nodos van acumulando más y más de estos datos, causando un serio problema de escalabilidad a largo plazo.
Por tanto, esto se gestionará de forma similar a la historia de la blockchain, pero más radicalmente. Hay que tener en cuenta que solo necesitamos que los datos de los Rollups estén “disponibles” el tiempo suficiente para que cualquiera pueda descargarlos y demostrar su validez. Por tanto, Ethereum se actualizará, permitiendo que los Rollups suban sus datos a la blockchain en un nuevo formato: los blobs. Serán estructuras de datos que serán borrados de la blockchain una vez haya pasado un mes desde que fueron publicados.
Danksharding
Ya podemos encajar al fin todas la piezas del puzzle, y descubrir cuál es el propósito final de Ethereum, el Danksharding: una combinación de todas estas actualizaciones, que sustituirá al modelo de sharding pensado originalmente. Comparemos las dos versiones.
El Sharding original
En el diseño de Sharding planeado originalmente para después del Merge, Ethereum estaría compuesta por 64 shards (fragmentos) y por la Beacon Chain.
- Las Shards serían una especie de blockchains individuales conectadas a la Beacon Chain, en las que se publicarían simplemente todos los datos de los Rollups. Serían blockchains de Data Availability. Serían validadas por comités del pool general de validadores de Ethereum, que rotarían pseudo-aleatoriamente para evitar posibles efectos de centralización.
- La Beacon Chain sería la fusión del Ethereum actual con consenso PoS. Se encargaría de coordinar al pool de validadores y a las 64 shards. Los bloques de las shards irían apareciendo de forma coordinada en los slots de la Beacon Chain.
Este modelo ofrece numerosos problemas, entre ellos, que para que todas las shards estén adecuadamente coordinadas, tienen que haber una sincronización excepcional entre todos los nodos de Ethereum, lo cual tal vez sea demasiado optimista. Además, la asignación aleatoria de los comités a las shards no es tan trivial como parece…
Danksharding
Es por ello que ha surgido un modelo mucho más sencillo y directo, producto de todas las mejoras de las que he ido escribiendo en este artículo: el Danksharding. Consiste en lo siguiente:
Para empezar, olvidémonos de las shards. En cada slot de la Beacon Chain se colocará un bloque enorme, construido por los builders gracias al Proposer-Builder Separation. Ese bloque será analizado, mediante Data Availability Sampling, por el comité de validadores asignado al correspondiente slot. Y ya está. Así de simple.
De esta forma podemos repartir equitativamente a todos los validadores a lo largo de toda una época de la Beacon Chain, y asegurarnos que no haya problemas, ya que no deben sincronizarse con ninguna shard.
Seguramente te estés preguntando… ¿y por qué aparece el término “sharding” en Danksharding? Pues porque queda “bonito”. Y porque podemos considerar fragmentado el hecho de que los validadores puedan comprobar la validez del mega-bloque que se les asigna en su slot simplemente descargando una pequeña parte de él (un fragmento). De hecho, serían simplemente dos filas y dos columnas de un bloque de 512 filas y 512 columnas. Impresionante, ¿verdad?
Conclusión: ¿será esto suficiente?
Un mundo ideal
Y con esto hemos concluido nuestra mirada hacia el supuesto futuro de Ethereum. Una vez llegue (si es que llega) el Danksharding, veríamos bloques de un espacio inmenso, y cualquiera de nosotros, con el suficiente ETH, y un ordenador modesto, podríamos participar en el mecanismo de consenso de Ethereum para validarlos. Los Rollups disfrutarían de casi ningún impedimento en subir su brutal cantidad de datos a la blockchain, y se reflejaría enormemente en un aumento de sus TPS (Transacciones Por Segundo) y en una disminución de sus costes de gas, haciéndonos la vida muchísimo más fácil. Pero claro, esta es la situación ideal…
KISS (Keep It Simple, Stupid)
Un principio muy considerado en el mundo científico es el de la Navaja de Ockham: “la explicación más sencilla suele ser la más probable”. Dándole un par de vueltas a la frase podemos aplicarla sobre el Roadmap de Ethereum: muchos investigadores y programadores trabajando sin descanso en sus actualizaciones, y una cantidad inmensa de tecnología para cubrir todos sus fallos, con enormes retrasos en cuanto a su implementación (véase el Merge) y muchas promesas, que no sabemos si se cumplirán. Es cierto que se dice que el camino de la descentralización no sigue atajos, pero también es posible que esto se les esté yendo de las manos. Mientras tanto, hay mucho tiempo y espacio para Layer 1 alternativas de usar sus modelos novedosos y con los problemas de Ethereum resueltos por defecto para tratar de destronar a la Reina de las DeFi.
El Rollup está centralizado, ¿quién lo descentralizará?
Está muy bien eso de que el Ethereum del futuro esté compuesto por una inmensa red de validadores descentralizada. Sin embargo, hay un problema que hoy en día muchos pasan por alto…
Te propongo un ejercicio sencillo: navega a L2Beat, la página web más famosa que sigue la evolución de todos los Layer 2 de Ethereum. 4 Billones de dólares de TVL actualmente. Haz click en el primer Rollup que encuentres (seguramente sea Arbitrum, tal vez Optimism). Oh, vaya:
El sequencer que aparece en todos estos Rollups no es otro que el único nodo que controla su cadena de bloques. Se encarga de ordenar las transacciones como le place y publicarlas en Ethereum. UNO SOLO. Es decir, si no le gusta tu transacción, puede omitirla sin problemas. Es cierto que tú mismo podrías forzar su inclusión en algunos de estos Rollups en Ethereum (ojo, que Starknet, por ejemplo, no da esta opción), aunque seguramente te cueste una buena tarifa, cortesía de mainnet, y no es el caso de uso ideal de un Layer 2, desde luego. Es cierto que puedes comprobar que las transacciones sean válidas con Fraud Proofs y zk-Proofs (nótese que en Optimism todavía no se puede, y que en Arbitum solo lo pueden hacer los miembros de una whitelist), pero contra la censura por ahora no se puede hacer mucho…
Entonces me pregunto… ¿de qué sirve que Ethereum esté descentralizado cuando la información que le llega está ya por defecto centralizada? La respuesta temporal es que todos estos Rollups están en proceso de hallar un modo de descentralizar a su sequencer, y de mejorar su sistema de Fraud Proofs. Pero de nuevo, volvemos al territorio de las promesas. La tecnología Rollup todavía está en proceso de asentamiento…
La guerra de los Rollups
El aspecto final a considerar es que, como tú mismo habrás comprobado en L2Beat, hay muuchos Rollupus y Layer 2. ¿Qué nos espera en el futuro en Ethereum? ¿Vivirán varios Rollups en armonía, o solo quedará uno? Ahora mismo son básicamente islas: han fragmentado la liquidez de Ethereum, y no es tan fácil ni seguro (basta con mirar nuestra newsletter, los bridges conllevan sus riesgos) transferir tokens o ETH entre ellos. En qué Rollup confiar es sin duda una incógnita muy seria a tener en cuenta. ¿Por cuál de los dos futuros deberíamos apostar? ¿Nos vamos a Polygon y ya está? Es algo que solo el tiempo nos dirá.
Hasta entonces, no dudes en continuar leyéndonos, en beToken My Friend, para enterarte de cómo se desenvuelve este auténtico culebrón, y de mucho más. Y si te ha gustado o incluso te ha sido útil este artículo, ¡no dudes en compartirlo!
No lo dudes, suscríbete y mantente al día de todo lo que sucede en el Cryptoverso y de la evolución de Tokeners DAO 👇👇👇👇👇
Y si te ha gustado este post… ¡Compártelo! Ayuda a difundir las Cryptos.
Nos encanta recoger todas las opiniones y puntos de vista. ¿Quieres colaborar con nosotros? Mira este post:
Disclosure
Los autores pueden poseer fondos y activos mencionados en este boletín.
beToken my Friend, es un boletín destinado únicamente a fines informativos. No pretende servir como asesoramiento de inversión. Consulte con su asesor de inversiones, fiscal o legal antes de tomar cualquier decisión de inversión.
La publicidad y el patrocinio no influyen en las decisiones editoriales ni en el contenido. Los anuncios de terceros y los enlaces a otros sitios donde se anuncian productos o servicios no son respaldos ni recomendaciones de beToken.
beToken no es responsable por el contenido de los anuncios, las promesas hechas o la calidad o confiabilidad de los productos o servicios ofrecidos en cualquier anuncio o contenido de terceros.
El Research Lab de beToken Capital es el promotor de beToken my Friend y parte del equipo de Genesis de Tokeners DAO.
beToken Capital lo componen un equipo de expertos en capital riesgo, mercados financieros y criptomonedas con el objetivo de contribuir a la democratización de las finanzas promoviendo la educación financiera de las personas.
Proporciona servicios de Institution-grade Research en Crypto (algunos de ellos los compartimos en beToken my Friend) y también invierte en fase temprana en las empresas y protocolos que van a revolucionar las Finanzas y la Web 3.0.