massimoalbarello/consensus_on_demand

Fast IC Consensus

This repo is an implementation of an improved consensus algorithm for the Internet Computer blockchain. The modified algorithm, called Fast Internet Computer Consensus (FICC), improves the latency of block finalization by 30% compared to the original Internet Computer Consensus (ICC).

Paper

More info: https://arxiv.org/abs/2312.05869

AWS deployment

To test the FICC implementation and compare it to the ICC implementation you have to setup n AWS EC2 instances (ideally at least 4 in different datacenters).

Create instances

While setting up an EC2 instance i in [1,n], use the following configurations:

• name: ex. ficc_peer_i
• OS: Ubuntu 22.04
• instance type: t2.small
• keypair: generate new RSA key to SSH into the instance and store it in ./keys. Give it a unique name (ex. peer_i_aws_rsa_key) as you will have to create one key for each instance
• storage: 50 GiB of gp3
• security: type All TCP source Anywhere-IPV4

Setup instances

Once the instances are up and running, open the setup_replicas.py file on your localhost. For each instance you created, insert a dictionary in the peers array.

peers = [
    {
        "number": <instance_i>,
        "ip": <public_IP_of_EC2_instance>,
        "web_server_port": "56790",
        "libp2p_port": "56789",
        "key_file": "<file_name_instance_rsa_key>.pem",
        "id": "",
        "remote_peers_addresses": "",
    },
    # other instances
]

Start the instances setup by running python3 setup_replicas.py. This program can easily run for 10 minutes. Once the script finishes, all instances should have a built Docker container ready to be executed.

Start instances

Once all instances are setup, copy the peers array in the start_replicas.py file and put the instance with number 1 as the last element of the peers array.

By default, the instances run for 300 seconds and them automatically exit. You can modify this by changing the constant T in the file (in seconds). You can change the subnet configurations by modifying the following variables:

• F: max number of faulty replicas
• P: max number of replicas not in pre-agreement for FP-finalization
• D: notarization delay (in milliseconds)
• FICC: True to run the FICC protocol, False to run the ICC protocol

To execute the script, run python3 start_replicas.py Once the instances terminate, the script stores the finalization latencies measured by each replica in the ./benchmark folder and plot the finalization latencies for replica 1.

Benchmark

Once you have run the subnets with different parameters, you can compare the results by displaying them as a box plot. To do this, open the file benchmark.py and update the results array. Create a dictionary for each run you want to compare with the following properties:

• folder: ./benchmark/<name_of_autogenerated_folder_for_a_run>
• name: meaningful description of the run

As an example:

results = [
    {
        "folder": "./benchmark/ICC_16_0_0_3000_60_1680033093",
        "label": "ICC n=16 f=0"
    },
    # results of other runs
]

Running python3 benchmark.py will show the comparison of the plot bars, one for each run.

consensus_on_demand's Issues

Cannot prevent mining from blocking

Once mining starts it blocks the whole program. Can still eventually receive messages/blocks thanks to buffer but everything is delayed.
Tried spawning task for mine_block but the program is still blocked by my_peer.broadcast_block().await.

Connection not kept alive

Connection with peer is not kept alive. If peer doesn't send messages for a while, it won't be able to do so anymore.
Check out swarm::KeepAlive enum.