[Faucet] Implement simple faucet service

[666lcz]

Overview

This PR implements a modularized and extensible Faucet service with a naive Coin selection/splitting/transferring algorithm. The goal is to have something simple deployed to the Devnet first while I will improve concurrency in subsequent PRs.

Algorithm

• The core algorithm is in src/faucet/simple_faucet.rs, which always uses two coins in the active address(one to split and sent to users, and the other to pay gas fee for operations such as splitting and transferring). It selects the two coin during initialization with highest balances.
• For each request, we will send the recipient 5 coins with 2000 gas each(10000 in total)(see rationale here)
• It assumes that during genesis, we will credit the active address owned by the faucet with an insanely high balance(e.g. u64 can handle around 32k requests, which should be enough for devnet)
• Always using two coins is clearly not scalable since all operations need to be sequential. Subsequent PRs will improve the concurrency by using a queue of gas objects

Architecture

• src/faucet contains logic for coin transferring/splitting
• Previously I was planning to expose the service as part of the existing JSON-RPC server instead of a new HTTP Server. However, it's important that we have access to the IP address of each request in order to do rate-limitting(not rate-limiting by number of network requests from each IP, but rate-limiting by number of gas coins transferred). But the JSON-RPC library we are using does not expose IP address. In addition, setting up a separate server makes it very easy for us to add new user-facing features

Next steps

• Deploy to the Devnet
• Add a wallet command for requesting gas
• Implement rate-limiting by IP and Sui address
• Improve concurrency

Testing

Added unit tests. I also did an end to end testing as below:

curl --location --request POST 'http://127.0.0.1:5003/gas' \
--header 'Content-Type: application/json' \
--data-raw '{
    "FixedAmountRequest": {
        "recipient": "D319FF9E39F619823D7B7D1F6E896B817AA1B113"
    }
}'

Response

{
    "transferred_gas_objects": [
        {
            "amount": 20,
            "id": "3d644dd136ea5cbb1340274de71155eb97ee5db5"
        },
        {
            "amount": 20,
            "id": "58e9ed7e78bae97a660dfd2a50ed6fb7c31ca8c1"
        },
        {
            "amount": 20,
            "id": "62ff612f693e73cab41ec3497ab51e8754a3e4fe"
        },
        {
            "amount": 20,
            "id": "939f7cefc7852def869582aee280f193420055ff"
        },
        {
            "amount": 20,
            "id": "e108dc836f010b4849268f2d9502116ecc0692a9"
        }
    ],
    "error": null
}

Used the wallet CLI to verify that the address indeed received these coins

wallet gas --address D319FF9E39F619823D7B7D1F6E896B817AA1B113
                Object ID                 |  Version   |  Gas Value
----------------------------------------------------------------------
 3CD35E0D65C5B5995C940106D1F4FB8CAF5025F7 |     0      |   100000
 3D644DD136EA5CBB1340274DE71155EB97EE5DB5 |     2      |     20
 536EA9BE19570114FEBB57890628E9C1C70FF1D8 |     0      |   100000
 58E9ED7E78BAE97A660DFD2A50ED6FB7C31CA8C1 |     2      |     20
 62FF612F693E73CAB41EC3497AB51E8754A3E4FE |     2      |     20
 939F7CEFC7852DEF869582AEE280F193420055FF |     2      |     20
 D045DD52E11A66BC38ACA068F0608617A525FA61 |     0      |   100000
 E108DC836F010B4849268F2D9502116ECC0692A9 |     2      |     20
 EAC90BCFE43192F3CB3B759B113285AD6F6FE114 |     0      |   100000
 ECDE9B62E605716C65AEC6A031DFE513E3BA26CD |     0      |   100000

[666lcz]

Addressed @bmwill and @patrickkuo 's comments

• removed the service layer
• removed Arc<Mutex<>>
• removed Send/Sync
• Renamed server.rs -> main.rs

[bmwill]

Thanks for making those changes to simplify this!

[bmwill]

What's the reasoning for wanting this to be generic?

[666lcz]

In case I want to experiment with a different implementation of Faucet(e.g., using a queue of gas objects,etc) for some traffic and can quickly switch to another one in case the more complicated implementation is failing.

[bmwill]

I don't have context on how the internal wallet handles concurrent access so we may just want to be careful and sure that this service still functions properly with parallel requests (although the concurrency_limit should act as that bottleneck)

[666lcz]

Yes the current implementation only work for CONCURRENCY_LIMIT = 1 but will relax this assumption in a subsequent PR

[oxade]

@666lcz thanks for handling this