Propuesta Alternativa para el Contrato Remasc en Ethereum/RSK

Published on Author lopez

Desde el lanzamiento de la testnet pública de RSK, el código fuente ha sido publicado. Y ahora, puedo escribir sobre algunos detalles de la actual implementatión.

La plataforma Ethereum soporta el concepto de contratas precompilados: contratos que se implementan directamente en el código de cada nodo implementando, claro que respetando compatibilidad entre lenguajes de implementación. En el caso de RSK, se agregaron dos contratos precompilados: el contrato Bridge, y el contrato Remasc. En este post, quiero proponer una implementación alternativa al contrato Remasc (todavía sin una propuesta concreta en código, no hay una descripción oficial de la conducta esperada del contrato Remasc).

¿Qué es el contrato Remasc? Por lo que sé (recuerden, todavía no hay una descripción publicada del mismo, sólo el código), es un contrato que asigna premios a los mineros, examinando la actividad reciente de la blockchain en proceso. Para calcular y asignar esos premios, tiene estado relacionado con a los bloques pasados de la blockchain, no le basta con la información del bloque actual en proceso. Este estado está  en esta clase. Además, hay  una transacción especial Remasc AGREGADA a CADA bloque minado, al final de la lista de transacciones del bloque (no hay bloque válido SIN esa transacción Remasc). Así, que al final del proceso del bloque, esa transacción especial es ejecutada.

Pero, de acuerdo al Ethereum Yellow Paper, hay un paso especial en el proceso de un bloque:

11. Block Finalisation
The process of finalising a block involves four stages:
(1) Validate (or, if mining, determine) ommers;
(2) validate (or, if mining, determine) transactions;
(3) apply rewards;
(4) verify (or, if mining, compute a valid) state and nonce.

Entonces, mi primer propuesta consiste en eliminar ese transacción “agregada compulsivamente” en cada bloque, y usar el paso de finalización de un bloque para calcular y asignar los premios a los mineros. De esta manera, podemos eliminar el cálculo del nonce de la cuenta remasc, el armado y firmado de esa transacción, la inclusión de esta transacción para que el bloque sea considerado válido, la serialización de esos datos, el almacenamiento del transaction receipt…. bien, todos esos recursos pueden liberarse, veo que usar una transacción explícita puede simplificarse.  Para mí, tener un proceso de premiado implícito al final de un bloque es un modo más simple de hacer las cosas. Y ya saben mi preferencia: simplicity pays 🙂

La otra propuesta, a ser evaluada y explorada, es simplificar el uso del almacenamiento. El cálculo del próximo estado podría ser ejecutado con la información YA disponible en la blockchain en proceso, ya esa información está disponible. Así, el uso actual de almacenamiento (storage) en la implementación, es más un hack por performance, que algo estrictamente necesario (punto a revisar, porque al no tener una descripción de las responsabilidades del contrato, desconozco lo que tiene para hacer). El cálculo del próximo estado puede ser ejecutado apelando a la información de la blockchain. Si es necesario acceder a ese estado rápidamente, el contrato puede apelar a un cache en memoria. Si fuera necesario algún dato que NO se pueda obtener de la blockchain, ahi sí: eso va al storage, así todos los nodos pueden a partir de ahí calcular el nuevo estado. El storage en Ethereum es costoso, y RSK no es la excepción: en la implementación actual, luego de haber procesado 100000 en mi máquina con un nodo local conectado a la testnet, el espacio en disco ocupado por el contrato Remasc da cuenta de UN TERCIO del espacio total.

Nos leemos!

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