gitcoinbot
commented
5 years ago Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work has been started.
These users each claimed they can complete the work by 2 weeks, 4 days ago. Please review their action plans below:
1) levalleux-ludo has started work.
Hi, here is my plan :
- develop the new class JournalTrieCache as proposed, implementing the same interface as MutableTrieCache (ie MutableTrie).
- add unit test JournalTrieCacheTest with the same tests cases as MutableTrieCacheTest, to verify the new class functional behaviour is stricly the same as MutableTrieCache; Eventually add some new usecases to improve completeness if necessary
- Change the MutableRepository so that the method startTracking() returns a JournalTrieCache (instead of MutableTrieCache today). Then all transactions and program calls will be using the new cache, whereas the BlockExecutor is still using the MutableTrieCache (returned by ReporistoryLocator::startTRackingAt())
- Re-run (at least) RepositoryTest to verify the changes doesn't change the functional behaviour
- Re-run all tests to check any unexpected side effects.
Would you have any metrics / relevant usecases to assess the performances before and after these changes ? 2) michaeltendossemwanga has started work.
Optimizing the buffers Transforming cache system
Learn more on the Gitcoin Issue Details page.
levalleux-ludo
ghost
Prize Bounty
The Prize Bounty is 21 ETH.
Challenge Description
Currently the RSKj nodes employs a multi-level cache system to track changes to the world state. This allows to revert the state in case of REVERT opcode or OOG.
The main class involved is MutableTrieCache.java. Every new contract called gets a new MutableTrieCache on top of the previous one.
This implementation is sub-optimal in terms of efficiency. Put/get are O(N) operations, where N is the level of the cache while revert is O(1). It is preferable to use a journaling cache "JournalTrieCache" that:
The task is to change the structure of the node such that: for each block a MutableTrieCache is used, but for each transaction a JournalTrieCache is used (and the same object is is used for all internal CALL frames).
Submission Requirements
A valid submission should modify the RSKj node to implement JournalTrieCache integrated to transaction processing, pass all unit tests and synchronize with the RSK mainnet.
The code should respect the contribution standards specified in https://github.com/rsksmart/rskj/blob/master/CONTRIBUTING.md
Submission Deadline
The deadline for submissions is November 11, 2019.
Judging Criteria
The prize will be awarded to the best valid submission.
Winner Announcement Date
The submission will be reviewed between November 11 and November 18. Winners will be privately notified before a public announcement of all hackathon prices given by IOV Labs. The announcement and prize payouts will occur before November 31, 2019.