Angel \”Java\” Lopez on Blog

June 24, 2017

Alternative Proposal for Remasc Contract in Ethereum/RSK

Filed under: Blockchain, Ethereum, RSK, Uncategorized — ajlopez @ 5:37 pm

Since the release of public RSK testnet, the source code was published. And now, I can write about implementation details.

Ethereum platform supports the concept of precompiled contracts: contracts that are already implemented in the node code. In the case of RSK, we have two additional precompiled contracts: the Bridge contract, and the Remasc contract. In this post, I will propose an alternative implementation for Remasc contract (not yet with source code, there is no published official description for Remasc contract).

What is Remasc contract? AFAIK (remember, there is no public description yet), it is a contract that assign rewards to miners, examining the recent blockchain story. In order to calculate and assign rewards, it should have state related to the past blocks in the blockchain. This is the current state class. Also, there is a special Remasc transaction ADDED to EACH mined block, at the end of the list of transactions. And the target account is the Remasc contract. So, at the end of execution, that transaction is executed.

According to Ethereum Yellow Paper, there is a block finalization step:

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.

So, my first proposal is to remove the “compulsive added” transaction, and use the block finalization to invoke the contract. In this way, I could get rid off the nonce calculation, signing of transaction, block validation (a block SHOULD have that transaction), transaction serialization, transaction receipt storage, block transactions storage, etc….  To me, it is clear that having the reward process in the block finalization step instead of into an explicit transaction, is a simpler way. And you know, simplicity pays 🙂

The other proposal, to be explored, is to simplify the use of storage. The calculation of the next state could be performed with the blockchain information, already available. So, the current storage use is only a performance hack, that could be replaced, if needed, by an in-memory cache, removing the use of public blockchain storage. Ethereum storage is costly, and RSK is not an exception: in the current implementation, after more than 100000 blocks in testnet, running a local node in my machine, the Remasc storage takes 1/3 (one third) of total local storage. The Remasc should be deterministic, as any other contract. If for some reason it needs storage (to be reviewed when the specification is published)t, my first guess is that it needs less space than current implementation.

Stay tuned!

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

 

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: