CIC Software¶
Technology Setup¶
Generally the technical setup is done by a local Platform Service Provider like Grassroots Economics. The more local the better.
- Open Source (CopyLeft) Software: Ensure that you trust the software being used and that even if it is open source now, that improvements and upgrades will remain open source. Check out our stack.
- Distributed Ledger: We highly recommend developing your own ledger system where members of the community hold nodes that decentralize and secure the ledger.
- Interfaces / Wallets: We’ve built custodial systems that enable users to assign guardians that can help them reset lost passwords.
- Data Sharing: Given the consent of the community, anonymous transaction data can be recorded and displayed
CIC Stack Summary¶
While work toward non-custodial and web interfaces are underway, the CIC Stack is currently a custodial wallet and blockchain bidirectional interface engine for community inclusion currencies
- Fully Open source GPL 3.0 License
- Automates the full lifecycle of blockchain transactions
- Chain agnostic by design
- Introduces a new chain library toolset written from scratch
- Modular design with fully standalone but recombinable components
- Includes a broad collection CLI tools for most common chain and engine operations
- Empowers implementers to choose their level of abstraction
- Supports both local, containerized and decentralized environments
- Support last mile front-end apis and integrations
System parts¶
- Base components, containing all necessary provisions for services and tooling. (Chaintools)
- Generic services components, libraries, daemons and services making up the custodial engine. (cicnet)
- Deployment components, which facilitates deployment of the custodial engine, as well as seeding data for development, demonstration and migration. (GrassrootsEconomics)
- Test Coverage
Base components¶
- Queue handling (chainqueue): Makes sure that a transaction sent on behalf of a user is sent, resubmitted if stalled, and whose execution is verified by quering the network state.
- Chain syncing, (chainsyncer): Retrieves all state changes from the network and executes an arbitary number of code fragments per transaction.
- RPC (Remote Procedure Call) interface, which divides in two parts:
- Generic interface (chainlib): Concepts common to all chain-like RPCs, and provides a thread-safe interaction framework.
- Ethereum interface (chainlib-eth): An extension of the former for the Ethereum/EVM network.
- Chain tooling (chainlib, chainlib-eth): Granular access to all conceptual layers of chain interaction, including binary serializations and application interfaces, along with CLI (Command Line Interface) tooling framework.
- Signer, (crypto-dev-signer) Low-security keystore and signer which is easily usable in both production (provided that no external access is possible) and in any development environment.
- Configuration (confini): Incrementally merging configuration definition from multiple modules, and easily overriding them with command line flags and environment variables.
Generic services components¶
- All smart contract wrappers in the cicnet repository.
- CIC Contract registry (cic-eth-registry): Defines token and resource pointer lookup and authentication resources.
- Daemons and microservices in the apps subdirectories in the cic-internal-integration monorepo, specifically:
- cic-eth: Massively parallel and fault-tolerant implementation of the custodial signer/queuer/syncer engine, accepting tasks from end-users via middleware.
- cic-cache: Cache syncer and database fetching and storing details on transactions of interest.
- cic-ussd: State machine, microservices and gateway for end-users using the USSD (Unstructured Supplementary Service Data) interface via telcos.
- cic-notify: Pluggable notification engine, initially used only for SMS notifications to end-users.
Deployment components¶
- Data seeding and/or migrations for new development deployments. Located in the apps/data-seeding subdirectory of cic-internal-integration.
- Deployment and initialization of network resources (smart contracts etc) and initialization of the custodial engine. Located in the apps/contract-migrations subdirectory of cic-internal-integration.
Components by category¶
(in no particular order)
| area | category | components | maintainer | support | tech | relative complexity | maturity |
|---|---|---|---|---|---|---|---|
| chain queue/sync base | any | chainqueue, chainsyncer | Louis | ? | py | mid | hi |
| chain queue/sync engine | custodial | cic-eth, cic-eth-registry, cic-signer | Louis | Phil | py, celery | hi | hi |
| notifications | custodial | cic-notify | Phil | ? | py, celery | lo | mid |
| ussd wallet | custodial | cic-ussd | Phil | ? | py, celery | hi | hi |
| wallet interface translations | any | cic-translations | Will? | Phil | yaml? | lo | hi |
| HTTP authentications | custodial | usumbufu, cic-auth-helper | Louis | Blair, Sohail | py | hi | hi |
| python chain libaries | any | chainlib-eth, chainlib, | Louis | (community?) | py | mid | hi |
| python signer libraries | any | funga, funga-eth | Louis | ? | py | mid | hi |
| local queue and sync | non-custodial | chaind, chaind-eth, cic-batch | Louis | ? | py | mid | ? |
| contract interfaces | any | cic-contracts, eth-erc20, eth-owned, erc20-faucet, eth-interface | Louis | ? | solidity, py, bash | mid | hi |
| ge token contract | any | erc20-demurrage-token, sarafu-faucet | Louis | ? | solidity, py | hi | hi/lo |
| verificable claims base | any | okota | Louis | ? | solidity, py | mid | hi |
| cic analytics and aggregator | custodial | cic-data-golang | Blair | Darren | golang | mid | mid |
| cic analytics views | custodial | cic-data-golang | Darren | ? | grafana, golang? | mid | ? |
| web2 metadata store | custodial | cic-meta | ? | Louis | typescript | mid | hi |
| metadata protocol | any | crdt-meta | ~~Spence~~ | ~~Geoff~~, Louis | typescript | mid | hi |
| metadata schemas | any | cic-types | Phil | ~~Geoff~~ | py | mid | hi |
| contributor badge nft | non-custodial | (rose bootcamp project), nft-badgetoken | solidity, py, typescript, react(?) | Rose | Louis | mid | lo |
| web3 transition adapters | any | fadafada, fadafada-curl | Louis | (community?) | rust | mid | mid |
| cli cic creation | any | cic-cli | Phil | Louis | py | hi | mid |
| cli metadata viewer | custodial | clicada, cic-staff-installer | ? | Louis | py | lo | lo |
| ge blog | website | pelican website | Ida | Will | py, pelican | lo | hi |
| ge docs | website | docs webstie | Will | ? | py, (platform)? | mid? | mid |
| local dev bootstrap | devops | cic-stack | ? | all | bash, docker-compose | hi | hi |
| dev data seeding / migration | any | cic-stack | Phil | Louis | py, bash, typecsript | hi | hi |
| Telegram wallet | custodial | ? | Sohail? | ? | ? | ? | no |
| chain queue/sync interface | custodial | cic-eth-server, ... | Lum | ? | py | ? | ? |
| Web2 wallet | custodial | social recovery protocol | Lum | ? | ? | ? | no |
| P2P Services discovery | any | cic-p2p, village message protocol | Louis | ? | ? | ? | ? |
| Gas helpers | any | cic-gas-proxy, ethd-gas-sum | Louis | ? | py | lo | lo |
| Swarm provisions | non-custodial | libswarm-ng, pylibswarm | Louis | (community?) | c, py | mid | hi |
| Multisig | non-custodial | erc20-transfer-authorization | Louis | ? | solidity, py | mid | lo |
("Relative complexity" means complexity in relation to the function of the component.)
Deployment requirements¶
There are the requirements to run our complete software stack:
Blockchain infrastructure¶
- 3 x (2 CPU, 4GB RAM, 50+ GB Storage) for validator nodes future proofed for 1 yr across different cloud providers/data centers.
- n x (1 CPU, 2GB RAM) for prunning state nodes, useful for non-custodial web3 users tx submissions.
Custodial infrastructure¶
- Kubernetes preffered
- 4 CPU, 8GB RAM, 50+ GB Storage minimum (Includes additional monitoring components)
Last update:
2024-07-09