Este artículo ha sido escrito por Brenchy. GitHub.
Una de las propiedades fundamentales de los protocolos blockchain que utilizamos es la no-confianza, no necesitamos conocer ni confiar en los demás usuarios para que el sistema funcione de la manera esperada. Aun así, la mayoría de los usuarios que los utiliza lo hace confiando en lo que un tercero dice ser el estado real de la red.
Correr un cliente de blockchain no es una tarea trivial, se debe poder costear los recursos necesarios y hacerse el tiempo para mantenerlo. En este post, voy a hablar acerca de los light clients, una solución para permitir a los usuarios finales el acceso a la red en una manera similar a un nodo estándar, pero sin incurrir en todo el esfuerzo.
Ok Entonces, Que Es Un Light Client?
Un light client es una implementación liviana de un nodo, diseñada para correr en ambientes limitados como lo pueden ser exploradores web o sistemas embebidos.
La naturaleza de necesitar bajos recursos de los light clients permitirá que estos puedan ser implementados en celulares, billeteras, exploradores, o cualquier otra aplicación o hardware que necesite una conexión a la blockchain. Los requerimientos para almacenamiento, memoria y red son mínimos comparados con un nodo regular.
Importancia
os light clients son una pieza clave en un protocolo descentralizado. Sin ellos, la única manera viable en sistemas de bajos recursos de comunicarse con la blockchain es a través de providers.
Un provider es una entidad centralizada que facilita (provee) la infraestructura necesaria para fácilmente comunicarse con los nodos de la red Ethereum, utilizando una API estándar, siendo super convenientes para DApps y billeteras.
Los principales motivos para no utilizar providers son:
-
Datos: Manejan (y algunos colectan) muchos datos de los usuarios tal como direcciones IP, direcciones de cuentas, interacciones con contratos y queries de estado.
-
Censura: Las requests pueden ser bloqueadas por país de origen, cuenta de destino o de origen, o cualquier otra restricción impuesta o arbitraria.
-
Confianza: Las transacciones que pasan a través de providers pueden llegar ser aventajadas económicamente y la información recibida no es verificada.
Desafíos
Hay dos principales desafíos para las implementaciones de light clients que me gustaría repasar:
-
Verificar el estado de la blockchain sin almacenar la historia.
-
Seguir a la head de la blockchain sin utilizar muchos recursos.
El estado de Ethereum se almacena utilizando un Merkle Patricia Tree. Esta genial estructura de datos nos permite verificar datos específicos con una pequeña cantidad de hashes (merkle proofs) incluyendo a la raíz del Merkle Tree. Esta raíz del estado se encuentra almacenada en todos los bloques, por lo que solo necesitamos estar seguros de que el bloque es valido y pertenece a la cadena canónica, ademas de una manera para solicitar las pruebas necesarias para validar el dato especifico de nuestro interés.
En Ethereum PoW, sin finalidad de bloques, el segundo item era realmente un problema. En PoS, necesitábamos una manera de hacerlo sin utilizar muchos recursos, como lo seria si contáramos los votos de bloque valido de todo el set de validadores para saber cual es el header block. Por este motivo, en el hard fork Altair, se introdujeron los sync committees (comités de sincronía).
Sync Committee
El Sync Committee es un subset de validadores seleccionados al azar que tienen la responsabilidad de verificar y firmar los bloques subidos. Consisten de 512 validadores, los cuales son mezclados usando RANDAO cada 8192 slots (~27 horas).
Cuando se sube un nuevo bloque, cada uno de estos validadores verifican la transición de estado respecto al ultimo bloque y firman el bloque si esto es válido. Todas estas firmas se suben a la red y son agregadas por el constructor del bloque usando BLS, incluyendo esta firma agregada en el próximo bloque. Al menos 2/3 del comité tiene que firmar para que se considere a un bloque como valido y finalizado.
Esta firma luego puede ser verificada teniendo las llaves publicas o direcciones de cada validador en el comité, pero, ¿Cómo podríamos estar seguros de que el comité que nos envían es valido y es realmente el actualmente seleccionado por el protocolo? Para lograr esto debemos confiar en una raíz de estado anterior, y esto seria el weak subjectivity checkpoint.
Weak Subjectivity Checkpoint
Un weak subjectivity checkpoint (checkpoint de subjetividad débil) es un bloque o un estado anterior en la blockchain en el cual la red acuerda que que siempre perteneció a la red canónica, o sea, que es valido. Esto nos provee con una raíz de estado anterior en la cual podemos confiar, aunque existe un limite en el cual que tan atrás en el tiempo se puede plantear este checkpoint. La subjetividad proviene de no tener el estado histórico de la red, y confiar en algo que se acordó que es un punto valido en la blockchain.
Con esto podemos acceder al bloque actual, pero necesitamos llegar desde este punto en el pasado al presente.
Sync
Para ir desde nuestro checkpoint al comité de sincronismo actual, tenemos que iniciar este proceso solicitando cual fue el comité al momento del bloque de nuestro checkpoint, y el comité del próximo período. Este proceso se repite hasta que alcanzamos el comité que se encuentre firmando los bloques que estén siendo finalizados en el presente.
De esta manera, podemos estar seguros (en un nivel aceptable) de que nuestro comité es valido. Nos mantendremos observando actualizaciones de finalidad y siguiendo las raíces de estado, lo cual nos va a permitir verificar el estado de la blockchain una vez que tengamos las pruebas requeridas.
Obteniendo Las Pruebas
Para esto haremos uso del método RPC (EL) eth_getProof , el cual nos permite solicitar Merkle Proofs para verificar el estado de una cuenta. Los detalles de su implementación se encuentran en la EIP-1186 y se encuentra centrado en validación por cuenta, dependiendo la complejidad que puedan tener algunas operaciones, o cantidad de cuentas involucradas, sera más o menos eficiente.
Accediendo A La Red
Un light client sigue necesitando acceso a:
-
Capa de Consenso (CL) - Beacon API
-
Capa de Ejecución (EL) - Execution API
Se esta realizando progreso para acceder a ambas mediante comunicación P2P, pero mientras tanto aún si usamos un provider no estamos confiando en la información que nos envían, ya que podemos validar cada interacción.
Quisiera remarcar el trabajo llevado adelante por el equipo de Portal Network para exponer la capa de ejecución por P2P. Esta red va a estar compuesta por multiples redes p2p, cada una con una funcionalidad específica, y realizada de una manera en la cual todos los participantes de la red puedan contribuir a esta. Esto difiere ampliamente de LES, un protocolo basado en proveer soporte a light clients pero en el cual su arquitectura era del tipo cliente/servidor.
Conclusión
Espero haber podido generar interés acerca de esta gran tecnología. El beneficio que esto traerá a los usuarios finales es enorme, inclusive para aquellos que no están al tanto de cuanto se confía en la información que nos proveen terceros hoy en día. No hay duda de que existe mucho trabajo por delante, pero cualquier esfuerzo realizado en dar soporte a light clients o a las multiples implementaciones vale la pena para el beneficio de la red y los usuarios.
Recursos
-
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/
-
https://notes.ethereum.org/@vbuterin/extended_light_client_protocol
-
https://blog.chainsafe.io/the-road-ahead-for-ethereum-light-clients-b6fdb7c3b603
-
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity
-
https://mycelium.xyz/research/world-of-light-clients-ethereum
-
https://a16zcrypto.com/building-helios-ethereum-light-client/