CIC Software¶
Archive notice: The CIC stack and component inventory on this page documents historical Grassroots Economics infrastructure. Names, repositories, endpoints, maintainers, and deployment instructions may be obsolete and must not be treated as current CLC architecture.
Current software entry points¶
Use the CLC App and current CLC documentation for supported product and protocol behavior. Grassroots Economics developer material remains available at software.grassecon.org. The remainder of this page preserves historical CIC stack notes and architecture references.
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)