Versionado de Entidades en Ethereum/RSK

Published on Author lopez

En los dos años que pasaron, estuve escribiendo posts sobre blockchains, Ethereum, y el proyecto RSK. Varias veces, estuve escribiendo código experimental, en proyectos personales, o modificando código abierto publicado. Y en varias de esos experimentos, necesito agregar alguna información a la blockchain Ethereum/RSK. Un ejemplo: quiero escribir sobre soportar más de una máquina virtual, o el soporte de éter coloreado. En esos casos necesito agregar una información adicional en una Transaction o en un Account State.

Actualmente, los proyectos Ethereum y sus derivados, como Ethereum/RSK, codifican sus entidades a arreglos de bytes usando RLP (Run Length Prefix) encoding, especificado en el Yellow Paper. Usando una forma de codificación creada especialmente para este caso de uso asegura que todas las implementaciones usan el mismo formato, y como gran parte del consenso se basa en los hash resultantes de esos estados, el tener un formato base único asegura ese consenso en distintas implementaciones.

Internamente, cada entidad es serializada a una lista de items RLP ya encodeados. Si una entidad, por ejemplo una Account State, tiene dos campos internos, como balance y nonce, entonces la representación como lista RLP tiene DOS items.

Mi propuesta es: si necesitamos un campo o varios campos adicionales en una entidad de base, se puede discutir en la comunidad del proyectos, como cualquier otra propuesta. Pero una vez llegado a un acuerdo, la implementación seguiría un camino ya especificado. Tomemos como ejemplo el caso de arriba de AccountState. Inicialmente, su forma encodead tiene DOS items RLP en una lista, Cuando recibimos estos bytes encodeados, RLP nos puede decir LA CANTIDAD DE items de esa lista (lo sabe por la forma de codificación). Si la cantidad de items es DOS, entonces la representaci´n encodeada es la original, con dos campos, Pero si el número de items es mayor que DOS, el tercer campo sería un campo de un byte (o dos bytes) DECLARANDO LA VERSION de la codificación. Por ejemplo, si la versión es 1, entonces el cuarto item es el color del éter, y si la versión es 2, entonces el QUINTO item representa un campo agregado más tarde, en otro cambio.

Cuando serializamos un AccountState, si los campos adicionales tienen su valor asumido, solamente serializamos los DOS ITEMS iniciales, sin el campo de versión, y SIN los campos adicionales. De esta manera, la codificación es la misma que la original, y se toma como formal normal de codificación para este caso (en vez de tener campo de versión en 0 y dos campos adicionales con valores asumidos, probablemente 0), lo que facilita el consenso. Nunca serializamos el campo versión en 0. Si el primer campo adicional tiene valor no asumido, entonces pasamos a serializar con versión en 1, o versión en 2 si además el segundo campo adicional también tiene un valor no trivial.

Una nueva versión puede tener más de un campo adicional. En el ejemplo de arriba, sólo se considera que hay UN campo adicional en la versión 1, y otro en la versión 2, pero bien podría haber más campos.

Esta estrategia de serialización puede ser aplicada a entidades núcleo como

  • Bloques
  • Encabezamientos de Bloques
  • Estados de Cuentas
  • Transacciones
  • Recibos de Transacciones

Y cuando una nueva versión se acepta, no AFECTA a la serialización de las entidades anteriores.

Ahora, explicada esta estrategiam, puedo comenzar a escribir sobre la aplicación de estas ideas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez