yhassanzadeh13/lightchain-container

Containerized Implementation of LightChain Blockchain (research project)

Overview

This repository implements a proof-of-concept version of LightChain blockchain.

Running Simulation

Setting the parameters:

Modify the simulation parameters in simulation.config, which looks something like this:

nodeCount = 3 // number of nodes to spawn
iterations = 100 // The number of transactions to generate
pace = 1 // The time between every transaction generated (in seconds)
alpha = 10  // upper limit of attempts to search for validators
txmin = 1 // minimum number of Tx in a block
signaturesThreshold = 1 // minimum number of signatures to accept a block
initialBalance = 20  // balance to start with at launch
levels = 30  // length of nameID (levels of skip graph)
Mode = True // honest or malicious
validationFees = 1 // reward received by validator

Token = 20 // Represents any type of asset

// Mode of lightchain 
//(False -> original || True -> Smartcontract)
ContractMode = False 

Pre-requisite redarding smart contract integration

In solidityContracts folder put your .sol file. Detailed instructions are given in docs.

Running the simulation

Then you have to build the container. You need to do this step for any change in the code.

make build-container

Then you run the docker container. If needed, you can change the name of the docker container simdocker to anything else, provided you replace all other instances of the name subsequently.

sudo docker run --name simdocker -d lightchain

Then, to copy all the logs and the simulation results, use the following command:

sudo docker cp simdocker:/app/ .

Removing existing docker containers

If you have too many containers that are stopped and you want to remove them, the following command is useful:

sudo docker rm $(sudo docker ps -a -q)

Publications

• Hassanzadeh-Nazarabadi, Yahya, Alptekin Küpçü, and Öznur Özkasap. "LightChain: Scalable DHT-Based Blockchain." IEEE Transactions on Parallel and Distributed Systems 32.10 (2021): 2582-2593. (PDF)
• Hassanzadeh-Nazarabadi, Yahya, Nazir Nayal, Shadi Sameh Hamdan, Öznur Özkasap, and Alptekin Küpçü. "A containerized proof-of-concept implementation of lightchain system." In 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pp. 1-2. IEEE, 2020. (PDF)
• Hassanzadeh-Nazarabadi, Yahya, Alptekin Küpçü, and Öznur Özkasap. "Lightchain: A dht-based blockchain for resource constrained environments." arXiv preprint arXiv:1904.00375 (2019). (PDF)

Citation

For citing this implementation in a publication please use: Hassanzadeh-Nazarabadi, Yahya, Alptekin Küpçü, and Öznur Özkasap. "LightChain: Scalable DHT-Based Blockchain." IEEE Transactions on Parallel and Distributed Systems 32.10 (2021): 2582-2593.

@article{hassanzadeh2021lightchain,
  title={LightChain: Scalable DHT-Based Blockchain},
  author={Hassanzadeh-Nazarabadi, Yahya and K{\"u}p{\c{c}}{\"u}, Alptekin and {\"O}zkasap, {\"O}znur},
  journal={IEEE Transactions on Parallel and Distributed Systems},
  volume={32},
  number={10},
  pages={2582--2593},
  year={2021},
  publisher={IEEE}
}

lightchain-container's Issues

Implementations of LightChain

Hello,

Just came across your LightChain paper and now this Java based repo for LightChain and was wondering if you had, or know about, any Golang or Python implementations of LightChain that I could download and test?

Thanks and have a great day

[Debugging] fix test "testContractTransaction1"

1. testContractTransaction1: After building the docker container and running the simulation using the README provided in the github repo, testcon.sol is compiled into testcon.bin. I simply copied that file into the root directory of the project. Before doing this, testContractTransaction1 was failing because it couldn't find testcon.bin.

The compilation of the testcon.sol takes place in line 12 of the dockerfile

The possible solutions I can think of are:

a) just keep the compiled testcon.bin file in the repo — this is in fact what I pushed to the branch

b) figure out a way to do the compilation in the test itself. https://ethereum.stackexchange.com/questions/16299/compiling-smart-contract-in-java has a solution using processbuilder - 7 lines

Detect and Resolve Parallel Simulation Freeze

Context

When running a simulation of a number of nodes (above some certain number with some specific parameters) where nodes run in parallel each in a separate thread, the system suddenly freezes and nodes stop responding. We have postulated to possible reasons for this problem so far:

• While requests are going on between threads (nodes), some nodes are waiting for results from some other threads in such a way that it creates a circular dependency and a circular deadlock. We suspect that if this is the case, it happens at requests related to node insertions, because the lookup table of the skip graph implements locks to protect the info from concurrent reads and writes.
• We have used a software called Java VisualVM to track the status of the threads at the point where the deadlocks happens. The Analyzer which is supposed to detect and locate the deadlocks did not spot any. Instead it reported the following:
  • 62% of all threads are waiting for a monitor without a application thread holding it. This indicates a congestion. It is very likely the garbage collector is running and is blocking the monitors
  • And, it also pointed out that most of the threads are waiting for a single monitor, which is acquired by a single thread, which does not seem like a deadlock as in a circular thread dependency for example, but there might be another reason why the threads are blocking. Perhaps retrying with the program and making further analysis would make the problem clearer.

Task

The task is to recreate the simulation issue using several parameters, identifying the cause, and solving it.

Definition of Done

To work the changes on a separate branch and open a pull request after finishing the task.

Localnet Blocks Insertion

To develop following tests using builder. In following tests we skip the consensus and let nodes directly insert blocks into the chain. Also, blocks are empty of transactions (using just a nonce to make their hashes distinct). Let each node insert 100 blocks.

• One LightChain node sequentially inserting (empty) blocks, and keeps evaluating correctness of the latest block after each insertion.
• One LightChain node concurrently inserting (empty) blocks, and keeps evaluating correctness of the latest block after each insertion.
• Two LightChain nodes sequentially inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.
• Two LightChain nodes concurrently inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.
• System of LightChain nodes (~10) sequentilly inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.
• System of LightChain nodes (~10) concurrently inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.

Hex decode error

Hi Guys, I've just started working with LightChain, so I'm kind of new to it. I've installed the project and it seems to work except that it makes no block mining due to the following decode error:

It seems to do with the Contract, but I don't know what exactly. Do you know?
I'd really appreciate it if you cold help me with some hints. Thank you!

Deadlock Investigation

The following steps might be applied to investigate the true reason behind the deadlock

• Create a log file for every single node to be able to track its activity and find the sequence of actions carried out before deadlocking. Tracking for a large number of nodes might be difficult, but I would suggest to use a small number of nodes, and increase drastically the number iterations, which corresponds to the number of transactions inserted, resulting in many nodes being inserted in the overlay.
• Check the health of insertions. On can be done by storing a reference of all nodes in a list, and for each node, we may check that its numerical ID is less an its right and greater than its left, and also check if it is indeed the right neighbor of its left and left neighbor of its right. This way we may detect if the deadlock is caused by an inconsistency in the structure of the skip graph.
• Make extra monitoring around deadlocks, attempt to count lock acquiring attempts, and which cases are because the node acquired the lock and which cases the lock was released because of timeout. This can be appended to the information logs for each node.
• For numerical ID search, we may pass a map (for fast access), which marks if a node of a particular address, has been visited more than once on a search path, if this happens, we need to store the state of the current skip graph for reproducing this case.

[Debugging] fix test "testMineAttempt"

org.opentest4j.AssertionFailedError: new block was not properly added ==> Expected :11001110000100100000100111010135706429811001110000100100000100111010123355960oayxbzqjbd Actual :000000000000000000000000000000357064298

Suggestion: investigate whether the flag is updated correctly, i.e., after mining a new block the flag should point to it: blk.numID = flag.nameID

In general always flag.nameID should point to the latest block, and flag.numID should always be zero.

Please add a test verifying that when a block is mined correctly we have the flag updated accordingly.

Mock Network

To Implement a mock network for Lightchain.

This mock network will take requests from node and route them to other nodes manually. The difference is that the mock network will take references to all nodes available in the system, so that the message will be a basic function call to the destined node.

To make it more useful in terms of debugging, we may allow this mock network to support both concurrent and sequential runs. In concurrent we can create threads and make each function call run on a separate thread. Monitoring and observing custom threads is much easier and manageable than monitoring RMI threads. Also, the sequential option would allow us to ascertain whether any problem we have is concurrent or not.

A general use case for this mock network is as follows:

• We create several LightChain nodes separately.
• We create a mock network instance.
• References of LightChain nodes are given as a list to the mock networks and the mock network instance is given to each node, so that it can be used by the dummy LightChainNodeRMI described below.
• When each node has an instance of the mock network, a simple idea to integrate it into the current setup is to have dummy intermediary LightChainNodeRMI instances that connect the node to the mock network. In other words, when the lightchain node calls getRMI, instead of getting an instance to a LightChainNodeRMI, it will get an instance to a dummy object that implements that interface, and which also has an instance of the mock network. The dummy object will act as an intermediary between the mock network and the LightChain Node. It will route any request to the mock network and return the results through the dummy object.
• When the mock network receives a request, depending on its configuration (sequential or concurrent), it simply calls the function of the destination node with the given parameters and returns the result to the dummy node which consequently passes it to the original sender node.
• The idea of adding the dummy intermediary object is to inflict minimal changes on the structure if LightChain Node that we currently have.
• We can add several custom monitoring tools inside the mock network implementation, as well as timeouts and several other useful features. We can also implement a mechanism or format to generate customized runs only using the mock network, which is the main thing we will be doing.

[Debugging] fix test: "testGetLatestBlockExtensively"

org.opentest4j.AssertionFailedError: latest block wrong ==> Expected :000011111011011110110111111100838048897 Actual :000000000000000000000000000000838048897

The ending is the same but the starting part is different.

The first iteration runs fine, however, in the second iteration we get the error.

The error doesn't arise if we change the bottom if clause to if (i % 2 == 1) {

I think this might be because the insertBlock method works only if the prevAddress is different from the node's address and if the if clause remains as i%2==0, then the insertBlock doesn't work since prevAddress is equal to address in that case.

Decouple LightChain Implementation

LighChain shall be decoupled into 3 layers. The layers can be visualized as stacked on top of one another where every layer only interacts with the layer next to it. The layers are ordered from top to bottom as follows:

• LightChain Layer: Contains mostly the blockchain related functionalities. It is mostly decoupled but the point that will need re-design is LightChainRMIInterface, because this interface is highly related to the underlay, which lightchain should not interact with, LightChain layer should only have an instance of SkipGraph and use that instance to send messages and requests. For some specific functions of LightChain that are used in LightChainRMIInterface, these can be added as the message types supported by the underlay.

• Skip Graph Layer: This layer represents the skip graph implementation. It receives requests from LightChain layer, and routes those to the underlay which communicates with another nodes and returns the result to lightchain. This layer should have an instance of underlay which is used to send requests and receive responses.

• Underlay: This layer implements the protocol used to send and receive messages through the network. It basically holds all RMI related functions and provides an interface with the needed functions to the Skip Graph.

Backup Table Implementation

• To Implement Backup Table in addition to the Lookup Table we currently have.
• Instead of having a single skip node identity at every entry a lookup table.
• All nodes in the left entry are less than the current node and symmetrically for right entry.
• When routing a numerical ID search, or a name ID search, the search is routed to the closest node from the set.
• When a node is inserted it takes the left entry of the right node, and the right entry of the left node, and puts all node of numerical ID less than the inserted node to the left, and the rest to the right
• It might be a good idea to make both lookup tables implement some interface to ease switching from one to another.
• Full reference can be found here.

the two phase insertion implementation

Get Latest Block Testing

To test the getLatestBlock() functionality using a number of test scenarios:

• One LightChain node sequentially inserting (empty) blocks, and keeps evaluating correctness of the latest block after each insertion.
• One LightChain node concurrently inserting (empty) blocks, and keeps evaluating correctness of the latest block after each insertion.
• Two LightChain nodes sequentially inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.
• Two LightChain nodes concurrently inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.
• System of LightChain nodes (~10) sequentilly inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.
• System of LightChain nodes (~10) concurrently inserting (empty) blocks, and keep evaluating correctness of the latest block after each insertion.

[Networking] Clean underlay

Problem:

Two LightChain nodes communicating with each other in the current version of code are using JavaRMI. The RMI implementation is tightly coupled with the LightChain protocol code which introduces the following downsides:
1- There is no clean-cut between protocol and network: The LightChain protocol implementation should not be aware of the implementation details of the network layer, which is not the case, e.g., here). It needs to just use the network for sending and receiving messages and should not be bothered about how it is sending and receiving the message. All implementation logics should be completely abstracted away from the network layer.

2- Lack of modularity: we cannot swap in and out the RMI with other underlying implementations.

Solution:

• We are going to inspire from our clean Skip Graph project architecture (it is a separate project and we are not going to follow it up exactly, rather we are going to absorb the idea and implement it similarly here).
• The only thing the LightChain protocol should know about the protocol is an Underlay interface that can interact with to send and receive messages. Look at how underlay is implemented in Skip Graph project
• All network-layer interactions (i.e., those directly interact with primitives like RMI) should lay behind the Underlay and completely abstracted away.
• Similar to what we have done in the Skip Graph project, it should be only Underlay that knows about RMI shared methods. The LightChain protocol should be completely unaware of such implementation. At the protocol level, we should use the request type, and translate the request to proper RMI call at the underlay.

Definition of Done:

• We have an Underlay interface that abstracts away the entire networking primitives.
• The only functionality that LightChain protocol is aware of networking is this new Underlay interface.
• Underlay is implemented at the broadest level of abstraction with minimum endpoints basically sending and receiving messages of general types. As a general rule, Underlay in LightChain should not have any more number of methods than Underlay in Skip Graph project.
• New functionalities completely covered by tests.

Development rules:

• Fork a branch in the form of yourname/issuenumber-issuetopic from master.
• Develop on the branch.
• Make sure that your code is well-commented, documented, supported by tests, and clean.
• The code should not add any commented functionality. If you comment something out, it means that you should completely remove it.
• Open the PR and make sure that it passes the pipeline.
• Important note: Your PR should not change more than 200 lines of code. If the surface of your PR is large, please break it into smaller ones, each completely passing the CI pipeline and able to merge, and open them one-by-one, i.e., open the first micro-PR, let it be reviewed and merge, and go with the second.

[Testing] fix broken tests

Context:

• Running mvn test as part of our CI was supposed to run all tests and fail CI if any test would fail. However, we noticed that it is currently not configured properly, and hence there are a handful of broken tests sitting on master branch.

• The purpose of this issue is to configure the maven plugins in the project properly so that any broken test would fail the CI. As the candidate, we suggest Surefire plugin of maven be adopted to our project.

• Once the plugging is set properly, the broken tests should be identified, their root cause investigated, and fixed one by one.

How to proceed?

• Create a branch <yourname>/<issue-number>-<issue-name>
• Make sure that you setup the Surefire plugin has setup correctly so that mvn test will _run all tests in src/test/java/** packages. Even develop a simple test and intentionally let it fail to verify whether Surefire can catch it properly.
• Identify all broken tests, start by the easiest one to fix, and fix it, and repeat this process iteratively till all tests are passed.

Definition of Done:

• Surefire plugin has been configured properly.
• mvn test will run all tests in specified package and will detect and catch any broken test.
• All broken tests have been identified and fixed one by one.

Implement Mock Protocol

• To Implement a mock protocol that implements LightChainRMIInterface.
• This protocol will be used to route messages between nodes instead of RMI
• For simplicity this mock protocol can be made to store references to all nodes, and return these references instead of returning a remote RMI instance as the RMI currently works.

Mock Underlay

Context:

To test the application layer of LightChain, we need to mock out the RMI underlay implementation. However, we are not going to rely on the java-generated mock for this purpose. Rather, we are going to extend an instance of Underlay interface that keeps an inventory of all created underlays, and directly exchange messages between them:

public class MockUnderlay extends Underlay {
    private static HashMap<String, MockUnderlay> inventory;

    public MockUnderlay(String myAddress){
        inventory.put(myAddress, this);
    }


    @Override
    public GenericResponse sendMessage(GenericRequest req, String targetAddress) throws RemoteException, FileNotFoundException {
        try {
            return inventory.get(targetAddress).answer(req);
        } catch (NullPointerException e) {
            throw new RemoteException("target address not found");
        } catch (Exception e){
            // we should terminate if any other issue happened.
        }
    }

    @Override
    public boolean terminate() {
        return true;
    }

    public GenericResponse answer(GenericRequest req){
        // Here we address answering the generic request.
    }
}

Note: MockUnderlay should be implemented in src/main/java/underlay/mock/mockUnderlay.java.

Test Cases:

Test cases we should cover:

• When both underlays A and B are up and ready, their exchanged messages are delivered to each other intact.
• When A is down, B sending a message to A is gracefully notified of unsuccessful delivery. Here, by a graceful delivery we mean through a returned parameter or state variable, and without interfering with the normal flow of the program, throwing an exception, or causing to crash.
• Above test cases also covered for multiple messages being sent both sequentially and concurrently.

Definition of Done:

• Definition of Done:

• We have an Underlay interface that abstracts away the entire networking primitives.
• The only functionality that LightChain protocol is aware of networking is this new Underlay interface.
• Underlay is implemented at the broadest level of abstraction with minimum endpoints basically sending and receiving messages of general types. As a general rule, Underlay in LightChain should not have any more number of methods than Underlay in Skip Graph project.
• New functionalities completely covered by tests.

Development rules:

• Fork a branch in the form of yourname/issuenumber-issuetopic from master.
• Develop on the branch.
• Make sure that your code is well-commented, documented, supported by tests, and clean.
• The code should not add any commented functionality. If you comment something out, it means that you should completely remove it.
• Open the PR and make sure that it passes the pipeline.
• Important note: Your PR should not change more than 200 lines of code. If the surface of your PR is large, please break it into smaller ones, each completely passing the CI pipeline and able to merge, and open them one-by-one, i.e., open the first micro-PR, let it be reviewed and merge, and go with the second.